[rs6000] 64-bit integer loads/stores and FP instructions

[Segher Boessenkool]

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