[PATCH] ira: Fix old-reload targets [PR103974]

[Hans-Peter Nilsson]

> From: Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org>
> Date: Wed, 12 Jan 2022 16:58:50 +0100

> On 1/12/2022 8:00 AM, Richard Biener wrote:
> > On Wed, Jan 12, 2022 at 3:26 PM Vladimir Makarov <vmakarov@redhat.com> wrote:
> >>
> >> On 2022-01-12 03:47, Richard Biener wrote:
> >>> On Tue, Jan 11, 2022 at 7:41 PM Vladimir Makarov via Gcc-patches
> >>> <gcc-patches@gcc.gnu.org> wrote:
> >>>> On 2022-01-11 12:42, Richard Sandiford wrote:
> >>>>> The new IRA heuristics would need more work on old-reload targets,
> >>>>> since flattening needs to be able to undo the cost propagation.
> >>>>> It's doable, but hardly seems worth it.
> >>>> Agree. It is not worth to spend your time for work for reload.
> >>>>> This patch therefore makes all the new calls to
> >>>>> ira_subloop_allocnos_can_differ_p return false if !ira_use_lra_p.
> >>>>> The color_pass code that predated the new function (and that was
> >>>>> the source of ira_subloop_allocnos_can_differ_p) continues to
> >>>>> behave as before.
> >>>>>
> >>>>> It's a hack, but at least it has the advantage that the new parameter
> >>>>> would become obviously unused if reload and (!)ira_use_lra_p were
> >>>>> removed.  The hack should therefore disappear alongside reload.
> >>>> I have a feeling that it will stay for a long time if not forever.
> >>> We indeed seem to have 34 targets w/o LRA by default and only 15 with :/
> >>>
> >>> At some point Eric wrote a nice summary for how to transition targets
> >>> away from CC0, I wonder if there's something similar for transitioning
> >>> a port away from reload to LRA?  In those 34 targets there must be some
> >>> for which that's a relatively easy task?  I suppose it depends on how
> >>> much of the reload target hooks are put to use and how those translate
> >>> to LRA.
> >> First of all the target should be rid of using CC0.  Then theoretically
> >> :) the target should work with LRA as LRA uses existing reload hooks
> >> (more accurately a subset of them).
> > CC0 is no more, we've accomplished that feat for GCC 12!
> >
> >> In practice some work should be done for switching to LRA.  I did first
> >> 4 major targets to work with LRA and unfortunately did not find some
> >> repeating patterns in this work.  The problems for the first targets
> >> were mostly unique and required a lot of LRA code modifications.  After
> >> that people did other target switching pretty easily and spent few time
> >> for this as I remember.
> >>
> >> So based on my experience of porting targets to LRA I can not formalize
> >> this work.  But probably it can be done by examining all LRA targets
> >> code (mostly looking at machine dependent code related to use
> >> lra_in_progress_p) or by collecting information what was done from other

(About lra_in_progress_p, I see mixes of reload_in_progress
and lra_in_progress (no "_p") in supposed-switched-targets.
And shouldn't reload_completed be renamed (actually: some
kind or alias for) lra_completed to avoid confusion?)

I recall comments about code quality regressions.  Are there
actual numbers?  (Preferably from around the transition
time, because I bet targets still supporting "-mlra" have
regressed on the reload side since then.)

> >> people who did porting to LRA.
> > So in theory it might be just pulling the switch for some?  That is,
> > removing their definition of TARGET_LRA_P which then defaults
> > to true?
> >
> > Jeff might be able to test this for (all) targets on his harness.
> Given a patch, it's trivial do throw it in and see what the fallout is.

Again there's talk about LRA and comparing it to CC0, so
again I'll remind of the lack of documentation for LRA (in
contrast to CC0).  I'm not just referring to guides to use
for switching over a target to LRA, but sure, that'll help
too.

For starters, for each constraint and register-class macro
and hook, what's the difference between reload and LRA;
which ones are unused and which ones are new?

brgds, H-P