avr-gcc-list
[Top][All Lists]
Advanced

[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
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]