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