On Fri, Feb 08, 2019 at 11:46:37AM +0100, Eric Botcazou wrote: > > Backporting this is okay. (It was not done because it does not affect > > correctness). What is the "almost", btw? > > The predicate of operand #0 of movdi_internal32 is > rs6000_nonimmediate_operand > on the 7 branch and nonimmediate_operand on the 8 branch and later.
Ah k, that is fine of course. > > (In https://gcc.gnu.org/ml/gcc-patches/2016-11/txt4j9hLRLCzf.txt and you > > presumably mean the *movdi_internal32 hunk, and the first line of it: > > > > - "=Y, r, r, ?m, ?*d, ?*d, > > + "=Y, r, r, ^m, ^d, ^d, > > > > where the last three are mem<-reg, reg<-mem, reg<-reg, for fp regs). > > > > This patch was a year before we switched to LRA, and for non-LRA ports * > > does not do any register preferencing. > > Are you sure? No, I checked the docs so I wouldn't spout nonsense, but then I misread. Oops. > > For 6xx/7xx people *wanted* to use FP loads and stores whenever possible, > > because you get twice the bandwidth with them. > > > > If you do not want the FP registers used (or FP insns used), use > > -msoft-float, that's what it's for. > > No disagreement, but you can't force people to use it when they use FP code > in > other parts of their software. Believe me, we (and probably others) tried... Of course. And we try to use integer registers only in normal cases, these days. > > Patches are welcome, but complicating this already very complex code by > > introducing an arbitrary distinction between "embedded and other" (or > > actually, "server and other") isn't the way to go. Sorry. > > Not clear what you mean by complicating here... the approach is rather > simple > and precisely aimed at not disturbing the common path, i.e. server processors, > while preserving the historical path for other processors. AFAIK nobody has > evaluated the effects of the original change beyond POWER 7/8/9. You make an arbitrary distinction between certain CPUs and duplicate patterns based on that. > > Could you open a PR please? > > Sure, but about what now? ;-) About the bug: it should behave the same as before, use GPRs only in your testcase. Segher