[Bug target/46278] New: avr-gcc 4.5.1 doing suboptimal reloads using X

["georgjohann at web dot de" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46278

           Summary: avr-gcc 4.5.1 doing suboptimal reloads using X
           Product: gcc
           Version: 4.5.1
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: georgjohann@web.de
                CC: avr@gjlay.de
              Host: i686-linux-gnu
            Target: avr
             Build: i686-linux-gnu


Created attachment 22240
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22240
vektor-zeichen-i.c

Using avr-gcc-4.5.1, I 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 attached below.

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 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 a precompiled source. It basically does 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