Re: [avr-libc-dev] gcc-3.3 branch

[Marek Michalkiewicz]

> I was afraid of that, that's why i've been asking a number of times
> already for a review/discussion.  Too bad the discussion starts only
> now that gcc 3.3 is already around the corner.

It was around the corner for quite some time (release date was planned
for December) and I've been very busy - couldn't look into it earlier.

> It seems to fix the most problematic case though (i've also got this
> patch as an add-on patch in my FreeBSD port): indirect assignment to
> an IO register, without any postfix or prefix {in,de}crement.  The
> latter would probably not make that much sense for IO registers
> anyway.

The cases with Y or Z pointers are easy (just swap two instructions),
the case where the address happens to be in the X pointer is more
difficult (no nice X+d addressing mode, need to convert X+ to -X and
that might cost an instruction or two).

> Hmm.  Would it make sense to generally use the less efficient form,
> and then leave it to the optimizer to reorder the registers?  I wonder
> whether it would make sense to always try optimizing them unless
> forbidden by a "volatile" keyword.  That way, we could document that
> pointers to 16-bit IO registers are required to be declared "volatile"
> if a particular read/write order is required.  That sounds a bit like
> a crock, but should IMHO be within the possible actions for the
> "volatile" keyword.

Hmm, looks like a good idea - it seems out_movhi_mr_r could check
for "volatile" ("mem/v" in RTL dumps) with MEM_VOLATILE_P (dest).
Right now (again, sorry it's so late...), I'd rather not change
anything in the 3.3 branch, better test this in mainline first.

Marek