Re: [PATCH] Turn on LRA on all targets

[Segher Boessenkool <segher@kernel.crashing.org>]

On Mon, Apr 24, 2023 at 10:19:23AM +0200, Richard Biener wrote:
> On Sun, Apr 23, 2023 at 6:48 PM Segher Boessenkool
> <segher@kernel.crashing.org> 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.

(Note I misqualified a bunch under 1) that should be 2)).

> I think 1) and 2) where the default is LRA already should be changed to
> use the existing default and the ability to switch back to reload removed.
> That could be done independently and soon.

Sure.  Those categories of backends are easy to handle anyway.  Cat. 3
is the problematic category.

> > 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?
> 
> I think it's important to check that the targets still build, including a
> sensible set of their target libraries in a sensible set of their
> multilib configurations so they are not completely cut off from
> testing.
> 
> "Converting" targets one-by-one this way is sensible and appreciated.

Yes.  I sent this all-in-one simple-to-apply simple-to-test RFC patch
to try and get things moving, especially for all those targets where all
previous attempts have done nothing.

> > 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?
> 
> Did we announce a cut-off for reload going away?

I tried to do that in <https://inbox.sourceware.org/gcc-patches/febe8136ba2e1afbbf70beff8ce0a1cf66401dff.1672946731.git.segher@kernel.crashing.org/>
but it was decided we should not announce this in user documentation.
There has been talk about this on the developer mailing lists (and
elsewhere, irc for example) for ages, so it shouldn't come as a surprise
to anyone.

> Knowing the set of
> targets that fail to "auto-convert" within the above constraint would be
> nice.

Yes, but the response from most of the category 3 targets has been
thunderous silence :-/

I'll test how many targets fall down at my boring "build Linux" (so, the
kernel, not a distro :-) ) test, already.  A bit scared of doing that,
but it is time I guess.

> Thanks for pushing!

"It's a dirty job", etc.

So many ancient shortcomings of GCC cannot reasonably be solved while we
still allow old reload to be used (subregs of mem anyone?  But that is
just one example).  Let's see where this goes!


Segher