> 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

Reply via email to