[avr-gcc-list] >4.5.1 better than this at register-structure (xmega) access?

[Erik Walthinsen]

Something I've found and would like to get dealt with is the fact that 
avr-gcc 4.5.1 doesn't seem to properly comprehend the Xmega structures 
in avr-libc when it comes to efficiently loading and saving them.  It 
uses a pattern of loading the struct address into an address-register 
pair, then using offset load/store.  Sometimes I've even seen it waste 
*four* registers loading the struct address and adding a 16-bit offset 
before doing a full indirect load/store.  However, if I use the _ 
versions of the register definitions it does the efficient thing and 
lets the compiler calculate the address directly resulting in a single 
instruction:

void structwrite(uint8_t v) {
  TCC0.CTRLE = v;
 a6c:   e0 e0           ldi     r30, 0x00       ; 0
 a6e:   f8 e0           ldi     r31, 0x08       ; 8
 a70:   84 83           std     Z+4, r24        ; 0x04
}
 a72:   08 95           ret

void straightwrite(uint8_t v) {
  TCC0_CTRLE = v;
 a74:   80 93 04 08     sts     0x0804, r24
}
 a78:   08 95           ret

(and yes, I see this behavior *everywhere* I look, not just in simple 
examples like this)

This is a royal pain when I have my hardware-description header full of 
things like:

#define MILLISECOND_TIMER       TCC0

and code that wants to *consistently and quickly* access any arbitrary 
(but static at compile-time) member of that peripheral's structure. 
Instead I'm having to make a complete mess of my header with:

#define MILLISECOND_TIMER_CCA   TCC0_CCA

rather than just using MILLISECOND_TIMER.CCA and being done with it.


So, my question is: is this fixed in a newer version of the compiler, 
and thus worth my time to try to a) find all the patches, b) update my 
own patches for the various -U xmega chips, and c) compile the whole 
lot?  Or, is this problem still present?