[Bug c/100962] New: Poor optimization of AVR code when using structs in __flash

[Bug c/100962] New: Poor optimization of AVR code when using structs in __flash

[mojo at world3 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100962

            Bug ID: 100962
           Summary: Poor optimization of AVR code when using structs in
                    __flash
           Product: gcc
           Version: 5.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mojo at world3 dot net
  Target Milestone: ---

Example code here: https://godbolt.org/z/1hnPoGdTd

In this code a const __flash struct holds some data used to initialize
peripherals. Line 59 is the definition of the struct.

With the __flash attribute the generated AVR assembly uses the X register as a
pointer to the peripheral. The X pointer lacks displacement with LDI so rather
inefficient code is generated, e.g.

141     channels[ch].dma.ch->TRFCNT = BUFFER_SIZE;
142     channels[ch].dma.ch->REPCNT = 0;

        ldi r18,lo8(26)
        ldi r19,0
        adiw r26,4
        st X+,r18
        st X,r19
        sbiw r26,4+1
        adiw r26,6
        st X,__zero_reg__
        sbiw r26,6

Removing the __flash attribute produces much better code, with the Z register
used with displacement.

The issue appears to be because the other pointer register that supports
displacement, Y, is used for the stack so unavailable. Introducing the need to
use LPM instructions to read data from flash seems to cause Z not to be used
for the peripheral, with X used instead. Z is used only for LPM.

The best possible optimisation here seems to be to read all values needed from
flash first, and then switch to using Z as a pointer to the peripheral.

[Bug target/100962] Poor optimization of AVR code when using structs in __flash

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100962

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
You are using quite old (and unmaintained) GCC - does using newer GCC, like GCC
10 or GCC 11 improve things?

[Bug target/100962] Poor optimization of AVR code when using structs in __flash

[mojo at world3 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100962

--- Comment #2 from mojo at world3 dot net ---
avr-gcc-11.1.0-x64-windows>bin\avr-gcc -Og  -xc -Wall -mmcu=atxmega64a1u test.c
avr-gcc-11.1.0-x64-windows>bin\avr-objdump -h -S a.out > list.s

Still producing code like this

 2de:   18 97           sbiw    r26, 0x08       ; 8
 2e0:   19 96           adiw    r26, 0x09       ; 9

Thanks.

[Bug target/100962] Poor optimization of AVR code when using structs in __flash

[mojo at world3 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100962

--- Comment #3 from mojo at world3 dot net ---
Apologies, I noticed I had -Og on. Tried with -O3 and it optimised the struct
away. With -O2 it uses the Z register with displacement, reading data from
flash.

So it seems that only -Og produces poor code with V11. The older version 5.4.0
has issues either way. Not sure if that is a bug or just necessary for
debugging.

[Bug target/100962] Poor optimization of AVR code when using structs in __flash

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100962

--- Comment #4 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
Did you try option -mstrictX?

And try to make a problem-report self-contained.

[Bug target/100962] Poor optimization of AVR code when using structs in __flash

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100962

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #5 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
The code is optimized fine with -Os.

With -Og, you can expect less optimized code.  For the provided code and -Og,
you can improve code quality by means of -mstrict-X (where I am not sure
whether it would be appropriate to have -mstrict-X as the default).