On Sat, Feb 29, 2020 at 8:35 PM Jeff Law <l...@redhat.com> wrote: > > 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.
One could also simply pessimize R0 for RA via either an existing mechanism or a new target hook ... > 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 >
