On 10/11/2012 12:13 PM, David Kelly wrote:
Why should they have to know anything about AVR to optimize struct references?
Thus the testcase, it just happens to look like the AVR header. But I
think you're half right, half wrong: struct reference optimization is a
generic problem, but the specific solution ("ldi r30 loaddr,ldi r31
hiaddr,st Z,rX" or the better "sts addr,rX") is very AVR specific.
Am suspicious gcc is treating TCC0 as volatile, the address of the struct as
volatile, while the desire is for the contents to be volatile. Appears to be
defined as a pointer to a struct of volatiles, but perhaps the volatile
property is leaking?
That seems possible, and there's probably a decent way to build a
testcase to confirm that. I'm kinda doubtful that's what's going on,
but I don't know much of anything about the gcc internals either way.
Dereferencing TCC0.CTRLE by taking its address and casting it as a pointer may
strip volatile allowing gcc to optimize. It should be able to optimize anyway.
Hmm, I should check into my FS() workaround macro and make sure I'm
careful about the volatiles, it's possible I could shoot myself in the
foot with repeated hardware-register references using that...
FWIW, I *have* seen the compiler do the right thing with struct
references in the past, but it was for either read or write (I don't
remember which) and *not* the opposite. I have no idea what version of
compiler it was unfortunately.
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
