On Fri, Feb 03, 2017 at 09:59:45AM -0600, Segher Boessenkool wrote:
> Hi Jakub,
>
> On Fri, Feb 03, 2017 at 10:10:47AM +0100, Jakub Jelinek wrote:
> > As mentioned in the PR, for the following testcase we emit a power9
> > instruction even with -mcpu=power8. Similar movsf_hardfloat instruction
> > uses wb constraint for the stxssp insn source rather than wu, which it
> > only uses for stxsspx (power7?).
> >
> > Bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?
>
> Yes please. Thanks!
>
> Some testcase stuff below...
>
>
> > --- gcc/testsuite/gcc.target/powerpc/pr79354.c.jj 2017-02-03
> > 02:37:44.147938375 +0100
> > +++ gcc/testsuite/gcc.target/powerpc/pr79354.c 2017-02-03
> > 02:38:34.838303987 +0100
> > @@ -0,0 +1,23 @@
> > +/* PR target/79354 */
> > +/* { dg-do compile { target { powerpc64*-*-* && lp64 } } } */
The code that moves SFmode vector registers to GPRs needs -m64 (the convert
from scalar format to vector format puts the converted SFmode value in the
upper 32-bits of the vector register, and then after the direct move, it does a
32-bit shift right in the GPR). Similarly, going from a GPR to a vector
register, we do a shift left 32-bits, direct move, and then convert from vector
format to scalar format.
So to enable the code that was causing the problem, you need 64-bit. In
32-bit, it does a store, ori 2,2,0, and then a load to move SFmode values
between GPR and vector registers.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
