On 1/12/2022 8:00 AM, Richard Biener wrote:
On Wed, Jan 12, 2022 at 3:26 PM Vladimir Makarov <vmaka...@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