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. Cheers, Oleg
