What's the LRA way to do LEGITIMIZE_RELOAD_ADDRESS?

LRA does not use LEGITIMIZE_RELOAD_ADDRESS.  The LRA code knows how to make all addresses legal by itself.

.

Would someone please explain what has to be done?

It's likely more than just

#define TARGET_LRA_P hook_bool_void_true

I _thought_ https://gcc.gnu.org/wiki/reload had more instructions but it only talks about the target hook to start with.

Segher?

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

...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?

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

(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!

(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

LRA even breaks building libgcc: PR116324

The master branch has been updated by Georg-Johann Lay <gjl@gcc.gnu.org>:

https://gcc.gnu.org/g:49d58d8da2281ec66c376ca998d29652e417f4cd

commit r16-1733-g49d58d8da2281ec66c376ca998d29652e417f4cd
Author: Georg-Johann Lay <avr@gjlay.de>
Date:   Fri Jun 27 15:44:40 2025 +0200

    AVR: target/113934 - Use LRA per default.
    
    Now that the patches for PR120424 are upstream, the last known bug
    associated with avr+lra has been fixed: PR118591.  So we can pull the
    switch that turns on LRA per default.
    
    This patch only sets -mlra per default.  It doesn't do any Reload related
    cleanup or removal from the avr backend, hence -mno-lra still works.
    
    The only new problem is that gcc.dg/torture/pr64088.c fails with LRA
    but not with Reload.  Though that test case is awkward since it is UB
    but expects the compiler to behave in a specific way which avr-gcc
    doesn't do: PR116780.
    
    This patch also avoids a relative recent ICE that breaks building libgcc:
    R24:DI is allowed per hard_regno_mode_ok, but R26:SI is disallowed
    for Reload for old reasons.  Outcome is that a split2 pattern for
    R24:DI = zero_extend:DI (R22:SI) runs into an ICE.
    
    AVR-LibC builds fine with this patch.
    The AVR-LibC testsuite passes without errors.
    
    gcc/
            PR target/113934
            * config/avr/avr.opt (-mlra): Turn on per default.

Done.

Congratulations, and thank you!