Re: [PATCH] Turn on LRA on all targets

[Jeff Law <jeffreyalaw@gmail.com>]

On 4/23/23 10:47, Segher Boessenkool wrote:
> This minimal patch enables LRA for all targets.  It does not clean up
> the target code, nor does it do anything to generic code: it just
> deletes all target definitions of TARGET_LRA_P.
> 
> There are three kinds of changes:
> 
> 1) Targets that already always have LRA, but that redefine the hook
> anyway.  These are gcn, pdp11, rx, sparc, vax, and xtensa.  Nothing
> really changes for these targets with this patch (but later patches
> will delete the superfluous hook implementations).
> 2) Targets that have LRA selectable.  Some of those are probably fine,
> since they default to using LRA (arc, mips, s390).  Two others don't
> though, maybe because there are problems (ft32 and sh).  I'd love to
> hear from all targets in this category what the status is, how easy it
> was to convert, etc.
> 3) Targets that as of yet never used LRA.  Many of those will be fine,
> but some others will need a little tuning, and a few might need some
> actual improvements to LRA itself.  These are cris, epiphany, fr30,
> frv, h8300, ia64, iq2000, lm32, m32c, m32r, m68k, mcore, microblaze,
> mmix, mn10300, msp430, nvptx, pa, rl78, stormy16, and visium.  We'll
> find out how many of those targets are ever tested, and how many of
> those work with LRA without further changes, and how well.
> 
> I send this patch now so that people can start testing.  I don't plan to
> commit this for another week at least, for a week after GCC 13 release I
> guess?  How does that plan sound to people?
> 
> This is an RFC, so no changelog, no one can accidentally commit it :-)
> I thought about Cc:ing lots and lots of people, should I do that?ISTM that we ought to go through the non-LRA targets one by one to see 
which can be trivially converted and will still work.  Any that meet 
that criteria should just be converted.

While we may have some performance deltas, I would argue we just move 
forward.  The maintainers can and should be participating in getting us 
moved away from reload.

Of the list you mentioned, I would just remove m32c.  It hasn't been 
able to even build newlib in years and while I did spend some time 
debugging it, my conclusion was it was not salvagable.  It should just 
be deprecated.

For epiphany, it faults semi-randomly in reload last I looked and I 
haven't even tried to have the tester build newlib on that platform in 
eons.  I think epiphany should be deprecated as well.


Jeff