ira: Fix old-reload targets [PR103974]

  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.

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.

Tested on aarch64-linux-gnu and cris-elf.  OK to install?

Richard


gcc/
	PR rtl-optimization/103974
	* ira-int.h (ira_subloop_allocnos_can_differ_p): Take an
	extra argument, default true, that says whether old-reload
	targets should be excluded.
	* ira-color.c (color_pass): Pass false.
---
 gcc/ira-color.c |  3 ++-
 gcc/ira-int.h   | 10 ++++++++--
 2 files changed, 10 insertions(+), 3 deletions(-)
  

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. 
Recently I had the same problem.  My performance patch for IRA resulted 
in ice in reload pass on SH4.
> Tested on aarch64-linux-gnu and cris-elf.  OK to install?
OK.  Thank you.
>
>
> gcc/
> 	PR rtl-optimization/103974
> 	* ira-int.h (ira_subloop_allocnos_can_differ_p): Take an
> 	extra argument, default true, that says whether old-reload
> 	targets should be excluded.
> 	* ira-color.c (color_pass): Pass false.
  

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.

Richard.
  

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

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 
people who did porting to LRA.
  

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

Richard.
  

On Wed, Jan 12, 2022 at 4:00 PM Richard Biener
<richard.guenther@gmail.com> 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
> > 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?

I can confirm it works for visium which builds after such change and
can compile a hello world without crashing.  So it might be a viable
strathegy for the less maintained odd architectures we still have in
our tree.

> Jeff might be able to test this for (all) targets on his harness.
>
> Richard.
  

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

jeff
  

> 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
  

> 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
  

On Wed, 12 Jan 2022, Richard Biener via Gcc-patches wrote:

> > 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?
> 
> I can confirm it works for visium which builds after such change and
> can compile a hello world without crashing.  So it might be a viable
> strathegy for the less maintained odd architectures we still have in
> our tree.

 FWIW I have massaged the VAX backend sufficiently for the `vax-netbsdelf' 
target to successfully build with `-mlra' as the default.  There are still 
several ICE regressions throughout the testsuite however (none for old 
reload), to say nothing about severe code quality regression where it does 
build.  So there seems to be a lot of work to do there yet even if we let 
code quality regress with LRA.  I plan to do it, but it won't be quick.

  Maciej
  

> On Jan 12, 2022, at 1:13 PM, Hans-Peter Nilsson via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> 
>> ...
> 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.)

I haven't looked in a while, but it is certainly the case that the -mlra code out of pdp11 is not as good as that coming out of the old reload.  My understanding is that LRA isn't as friendly to memory-centric targets like pdp11 (and vax?).  In particular, from what I understood there is no support, or at least no significant support, for the pre-decrement and post-increment register indirect references that those targets like so much.

There was some suggestion along the lines of "please feel free to add it to LRA" but that's a seriously hairy undertaking for a programmer with no current knowledge of LRA at all.

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


What I found interesting is that apparently, to first approximation, supporting LRA amounted to "just turn it on".  I think there were some issues to fix in register classes or constraints, more along the lines of "these are things you should not do for either system but the old reload usually lets you get away with it".  So those were handled by cleaning up the issue in question generally, not as an LRA-specific change.

Compared to CC0 work the effort was vastly smaller, it's a major rewrite of the back end vs. a few small changes in a few spots.  But it's quite possible that the true picture is different and that there should be more changes.  And yes, there really should be documentation saying so.  GCCint has traditionally been quite excellent; it would be distressing if the creation of new technology like LRA causes it to regress.

	paul