> 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
Re: [PATCH] ira: Fix old-reload targets [PR103974]
Koning, Paul via Gcc-patches Wed, 12 Jan 2022 10:43:46 -0800
- [PATCH] ira: Fix old-reload targets [PR... Richard Sandiford via Gcc-patches
- Re: [PATCH] ira: Fix old-reload ta... Vladimir Makarov via Gcc-patches
- Re: [PATCH] ira: Fix old-reloa... Richard Biener via Gcc-patches
- Re: [PATCH] ira: Fix old-r... Vladimir Makarov via Gcc-patches
- Re: [PATCH] ira: Fix o... Richard Biener via Gcc-patches
- Re: [PATCH] ira: ... Richard Biener via Gcc-patches
- Re: [PATCH] i... Maciej W. Rozycki
- Re: [PATCH] ira: ... Jeff Law via Gcc-patches
- Re: [PATCH] i... Hans-Peter Nilsson via Gcc-patches
- Re: [PATCH] i... Hans-Peter Nilsson via Gcc-patches
- Re: [PATC... Koning, Paul via Gcc-patches