[Bug target/113934] New: Switch avr to LRA

[Bug target/113934] New: Switch avr to LRA

[sjames at gcc dot gnu.org]

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

            Bug ID: 113934
           Summary: Switch avr to LRA
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sjames at gcc dot gnu.org
                CC: chertykov at gmail dot com
            Blocks: 113932
  Target Milestone: ---

People are getting eager to require LRA. Please port the avr target to LRA (see
PR113932).

I remember some patch for this on the ML but I don't think it went in.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932
[Bug 113932] [meta-bug] Targets which should be ported to LRA

[Bug target/113934] Switch avr to LRA

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
What's the LRA way to do LEGITIMIZE_RELOAD_ADDRESS?

[Bug target/113934] Switch avr to LRA

[segher at gcc dot gnu.org]

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

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |segher at gcc dot gnu.org

--- Comment #2 from Segher Boessenkool <segher at gcc dot gnu.org> ---
LRA does not use LEGITIMIZE_RELOAD_ADDRESS.  The LRA code knows how to make all
addresses legal by itself.

[Bug target/113934] Switch avr to LRA

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-03-15

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.

[Bug target/113934] Switch avr to LRA

[gjl at gcc dot gnu.org]

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

--- Comment #4 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
Would someone please explain what has to be done?

It's likely more than just

#define TARGET_LRA_P hook_bool_void_true

[Bug target/113934] Switch avr to LRA

[sjames at gcc dot gnu.org]

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

--- Comment #5 from Sam James <sjames at gcc dot gnu.org> ---
I _thought_ https://gcc.gnu.org/wiki/reload had more instructions but it only
talks about the target hook to start with.

Segher?

[Bug target/113934] Switch avr to LRA

[gjl at gcc dot gnu.org]

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

--- Comment #6 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
...to be more specific:

TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P explains the function of the hook from the
perspective of someone who is implementing a register allocator, but there is
no explanation whether it is a good idea (or even required) to implement it for
some specific target.  What form can "subst" take?  When it's purpose it to
avoid spills, then why not always true? (Nobody wants stills when they can be
avoided).

TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT: How would I describe addressing
capabilities for different named address-spaces?  What kind of target code can
I use to investigate the effect of the hook? Or can it inferred simply from the
device's register layout?

TARGET_SPILL_CLASS:  Can't we just return GENERAL_REGS as a spill class?

TARGET_COMPUTE_PRESSURE_CLASSES:  Requests that we should compute pressure
classes.  Now I know everything about it ...kidding.  Again it's from the
perspective of someone who is writing a register allocator, but of no use for
someone who has to provide an implementation.

TARGET_ADDITIONAL_ALLOCNO_CLASS_P: Similar issue.

TARGET_REGISTER_PRIORITY: When some registers are preferred over others and
hence we give them a higher priority, might that lead to more MOVs or spills?

Finally: Who will fix fallout like ICEs (spill fails), performance issues, etc?
Just reporting them here as PR will likely not help much, because AVR is
ternary and hence any PR has priority P4 or less.  For example, Newlib dropped
AVR support because nobody did fix all the spill fail ICEs when building Newlib
for AVR.  lra just perform 2 rounds, and when it doesn't find an allocation it
just bails out with spill fail ICE.

[Bug target/113934] Switch avr to LRA

[gjl at gcc dot gnu.org]

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

--- Comment #7 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
...more questions:

What's the connexion between TARGET_REGISTER_PRIORITY and
ADJUST_REG_ALLOC_ORDER  / reg_alloc_order[].

What about reload_completed?  Does semantics stay the same? What about
reg_renumber[].  And reload_in_progress becomes lra_in_progress or what?

[Bug target/113934] Switch avr to LRA

[gjl at gcc dot gnu.org]

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

--- Comment #8 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
...more questions:

TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS: Same issue: This hook can change a
reload class.  The purpose is clear for regalloc guys, but when and d why and
how would I do it for a specific backend?  The hook has two "reg_class_t"
parameters as inputs, and no parameter does even have a name. "default hook
always returns given class" ... Which one? There are two indestinguishible
ones.

[Bug target/113934] Switch avr to LRA

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Georg-Johann Lay from comment #4)
> Would someone please explain what has to be done?
> 
> It's likely more than just
> 
> #define TARGET_LRA_P hook_bool_void_true

That is what you start with, though.  Or more likely, you have a -mlra flag to
enable/disable it during development.  You can do that *right now*, and that
enables other people to help you out with this, etc. :-)

Possibly some things will not work.  Either you need to do a bit of target
work, or maybe some of the general LRA code is not up to snuff yet.  No one
will know until someone tries out!

[Bug target/113934] Switch avr to LRA

[gjl at gcc dot gnu.org]

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

--- Comment #10 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #9)
> (In reply to Georg-Johann Lay from comment #4)
> > Would someone please explain what has to be done?
> > 
> > It's likely more than just
> > 
> > #define TARGET_LRA_P hook_bool_void_true
> 
> That is what you start with, though.  Or more likely, you have a -mlra
> flag to enable/disable it during development.  You can do that *right now*,
> and that enables other people to help you out with this, etc. :-)

Done: https://gcc.gnu.org/r15-2865

> Possibly some things will not work.

Ya, it's easier to break than I thought.  LRA already breaks for one of the
random programs I had lying around: PR116321

[Bug target/113934] Switch avr to LRA

[gjl at gcc dot gnu.org]

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

--- Comment #11 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
LRA even breaks building libgcc: PR116324

[Bug target/113934] Switch avr to LRA

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
Bug 113934 depends on bug 116321, which changed state.

Bug 116321 Summary: [lra][avr] internal compiler error: in avr_out_lpm_no_lpmx, at config/avr/avr.cc:4572
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116321

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

[Bug target/113934] Switch avr to LRA

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
Bug 113934 depends on bug 116326, which changed state.

Bug 116326 Summary: [lra] internal compiler error: in get_reload_reg, at lra-constraints.cc:755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116326

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

[Bug target/113934] Switch avr to LRA

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
Bug 113934 depends on bug 116324, which changed state.

Bug 116324 Summary: [lra] error: inconsistent operand constraints in an 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116324

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

[Bug target/113934] Switch avr to LRA

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
Bug 113934 depends on bug 116325, which changed state.

Bug 116325 Summary: [lra] ICE: in curr_insn_transform, at lra-constraints.cc:4283
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116325

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE