Minor regression due to recent IRA changes

[Jeff Law]

On Sun, 2020-03-01 at 10:37 +0900, Oleg Endo wrote:
> On Sat, 2020-02-29 at 12:35 -0700, Jeff Law wrote:
> > Yup.  That was roughly what I was thinking and roughly the worry I had with
> > trying to squash out the quality regressions.  But it may ultimately be the
> > only way to really resolve these issues.
> 
> Another idea would be to let RA see R0, but ignore all the R0
> constraints.  Then try fixing up everything afterwards.  If R0 is
> removed from the allocatable reg list, there will be one register less
> for it to work with and I'd expect some code quality regressions.  But
> in order to fix up all the R0 cases after the regular RA/reload, I
> believe it will have to re-do a lot of (similar) work that has been
> done by the regular RA already.  One thing that comes instantly to mind
> are loops and the use of R0 as index/base register in memory addressing
> ... it just sounds like a lot of duplicate work in general.
> 
> > DJ's work on the m32c IIRC might be useful if you do try to chase this stuff
> > down.  Essentially there weren't really enough registers.  So he had the port
> > pretend to have more than it really did, then had a post-reload pass to do
> > the
> > final allocation into the target's actual register file.
> > 
> 
> AFAIK DJ did the same (or similar) thing for RL78.  IMHO that just
> shows that one type of RA/reload does not fit all.  Perhaps it'd be
> better to have the option of different RA/reload implementations, which
> implement different strategies for different needs and priorities.
> 
> Anyway, on SH the R0 problem seems to go away with LRA for the most
> part.  I don't know if anything has been put in LRA specifically to
> address such cases, or it works by general definition of the design, or
> it's just a mere coincidence.  If it's the latter case, I'm not sure
> what to expect in the future.  Perhaps it will start breaking again if
> changes for other targets are being made to LRA.
FWIW I've got an sh4/sh4eb bootstrap and regression test running with
HONOR_REG_ALLOC_ORDER defined.  As Vlad mentioned, that may be a viable
workaround.

Jeff
>