[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [avr-gcc-list] avr-gcc 4.5.1 doing bad reloads using X
From: |
Weddington, Eric |
Subject: |
RE: [avr-gcc-list] avr-gcc 4.5.1 doing bad reloads using X |
Date: |
Tue, 2 Nov 2010 12:27:19 -0600 |
Thanks for doing this analysis! Would you also be willing to write up a GCC bug
report for this?
I'll see what we can do to get this fixed.
Eric Weddington
> -----Original Message-----
> From:
> address@hidden
> [mailto:address@hidden
> org] On Behalf Of Georg Lay
> Sent: Tuesday, November 02, 2010 10:42 AM
> To: address@hidden
> Subject: [avr-gcc-list] avr-gcc 4.5.1 doing bad reloads using X
>
> Hi, I compiled one of my projects with hard real-time constraints
> using avr-gcc-4.5.1 and observed the following issue concerning both
> code density and speed.
>
> avr-gcc-4.5.1 prefers to use X-reg to reload addresses. Just note the
> *movqi/3 and *movqi/4 sequences in the asm-printout below:
>
> ...
> adiw r26,18 ; 250 *movqi/4 [length = 3]
> ld r20,X
> sbiw r26,18
> adiw r26,25 ; 251 *movqi/4 [length = 3]
> ld r21,X
> sbiw r26,25
> add r20,r21 ; 252 addqi3/1 [length = 1]
> mul r24,r19 ; 253 *mulqi3_enh [length = 3]
> mov r24,r0
> clr r1
> add r20,r24 ; 254 addqi3/1 [length = 1]
> adiw r26,20 ; 255 *movqi/3 [length = 3]
> st X,r20
> sbiw r26,20
> mul r18,r19 ; 256 *mulqi3_enh [length = 3]
> mov r18,r0
> clr r1
> adiw r26,19 ; 257 *movqi/4 [length = 3]
> ld r24,X
> sbiw r26,19
> add r18,r24 ; 258 addqi3/1 [length = 1]
> adiw r26,21 ; 259 *movqi/3 [length = 3]
> st X,r18
> sbiw r26,21
> sbi 62-0x20,5 ; 264 *sbi [length = 1]
> adiw r26,23 ; 265 *movqi/4 [length = 3]
> ld r24,X
> sbiw r26,23
> subi r24,lo8(-(2)) ; 266 addqi3/2 [length = 1]
> adiw r26,23 ; 267 *movqi/3 [length = 3]
> st X,r24
> sbiw r26,23
> rjmp .L58 ; 710 jump [length = 1]
> .L22:
> adiw r26,11+1 ; 272 *movhi/3 [length = 4]
> st X,r31
> st -X,r30
> sbiw r26,11
> adiw r26,16 ; 273 *movqi/4 [length = 3]
> ld r21,X
> sbiw r26,16
> tst r21 ; 274 *cmpqi/1 [length = 1]
> brne .L25 ; 275 branch [length = 1]
> tst r18 ; 277 *cmpqi/1 [length = 1]
> brne .L25 ; 278 branch [length = 1]
> adiw r26,20 ; 280 *movqi/4 [length = 3]
> ld r21,X
> ...
>
> All these memory accesses could be made by means of Y+const and most
> of the code consists of adding/subtracting constants to/from X.
> Hacking source (or using avr-gcc-3.4.6) so that Y gets used to address
> SRAM leads to code deflation from ~1200 bytes to ~950 bytes.
>
> Without tracking it down, I think it's an avr backend issue because it
> is lying at IRA and reports wrong reload costs: Both X+const, Y+const
> and Z+const are handled by the same constraint alternative(s), but the
> costs of X+const are considerably higher because there is no native
> instruction for it. IRA uses X and not Y because Y would cause
> prologue/epilogue costs. However, the accumulated additional costs of
> using X are much higher than the prologue/epilogue costs that would
> arise if Y was used.
>
> So the backend badly needs new memory constraints that report costs to
> IRA. I would highly recommend to use multi-letter constraints for that
> so that the backend won't run out of constraint letters
> sooner or later...
>
> Being not familiar with LEGITIMIZE_RELOAD_ADDRESS, I wonder if there
> is a way to describe costs therein, or maybe that hook is an
> anachronism that it no more needed with IRA?
>
> To reproduce this, I attached some precompiled sources. The excerpt
> abive is compiled from vektor-zeichen-i.c. They basically do indirect
> accesses to struct components of one struct in SRAM, so nothing
> complicated. Register pressure is quite low so that is no issue.
>
> Compiled with
>
> avr-gcc-4.5.1 vektor-zeichen-i.c -S -Os -mmcu=atmega168 -ffixed-6
> -ffixed-7 -mmcu=atmega168 -dp -fverbose-asm
>
> avr-gcc-4.5.1 snake-i.c -S -Os -dp -mmcu=atmega168 -fverbose-asm
> -std=gnu99
>
> Cheers, Georg
>