|
From: | Erik Walthinsen |
Subject: | Re: [avr-gcc-list] >4.5.1 better than this at register-structure (xmega) access? |
Date: | Thu, 11 Oct 2012 12:22:09 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 |
On 10/11/2012 12:13 PM, David Kelly wrote:
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.Why should they have to know anything about AVR to optimize struct references?
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.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?
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...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.
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.
[Prev in Thread] | Current Thread | [Next in Thread] |