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 >
