Re: [PATCH #2], PR target/81959, Fix ++int to _Float128 conversion on power9

[Segher Boessenkool <segher@kernel.crashing.org>]

Hi!

On Thu, Nov 30, 2017 at 04:52:44PM -0500, Michael Meissner wrote:
> No, then it tends to generate worse code if it is done before the first split
> pass (because it no longer keeps the address together).  I've been thinking
> that in general, we should replace these calls with a new predicate that before
> register allocation allows normal memory addresses, but during/after RA, it
> becomes more strict.  In my experience, with RELOAD that wasn't feasible, but
> LRA can handle it (and RELOAD is no longer an issue).

Can't you use the "strict" arg to legitimate_address_p and friends?

> > --- gcc/testsuite/gcc.target/powerpc/pr81959.c	(revision 0)
> > +++ gcc/testsuite/gcc.target/powerpc/pr81959.c	(revision 0)
> > @@ -0,0 +1,25 @@
> > +/* { dg-do compile { target { powerpc64*-*-* && lp64 } } } */
> > +/* { dg-require-effective-target powerpc_p9vector_ok } */
> > +/* { dg-options "-mpower9-vector -O2 -mfloat128" } */
> 
> powerpc*-*-*, or does that not work?
> 
> It needs 64-bit because various machine independent parts of the compiler want
> to use TImode if there is arithmetic support for KFmode to copy things, and
> TImode isn't supported in 32-bit.

That's what lp64 is for.

> The __float128 support is not built if the compiler is a 32-bit compiler (the
> enabler for _float128 is in linux64.h)

So we need some bugzilla predicate for that really?

Okay for trunk.  Further improvements welcome ;-)  Thanks!


Segher