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