On Sun, 2020-03-01 at 01:47 +0900, Oleg Endo wrote: > On Sat, 2020-02-29 at 09:38 -0700, Jeff Law wrote: > > It really would have just been a workaround for some of the R0 issues > > anyway. > > I think at its core R0 on the SH probably needs to be treated more like a > > temporary rather than a general register. But that's probably a huge > > change, > > both in terms of just getting it working right and in terms of addressing > > the > > code quality regressions that would introduce. > > > > I think one of the major issues is that R0 is a constraint in several > addressing modes for memory accesses. I believe I once had the idea of > hiding R0 from RA ... then insert reg-reg copies (to load R0) after > RA/reload ... and then somehow do back propagation to get rid of the > reg-reg copies again. Another idea was to run a pre-RA pass to pre- > allocate all R0 things. But I think it's all just running in sqrt(1) > circles after all. 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.
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. jeff
