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

[Michael Meissner <meissner@linux.vnet.ibm.com>]

On Fri, Dec 01, 2017 at 05:33:39PM -0600, Segher Boessenkool wrote:
> 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?

Well legitimate_address_p allows various D-form address, pre-inc/pre-dec, etc.
It has no context on what the address is being used for.  Secondary reload does
have the context, but I've seen post reload passes redo stuff (and typically
then it has to add more code to match the constraints once again).

> > > --- 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?

Or possibly implement the support in 32-bit compilers (and not break embedded
targets).

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

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.vnet.ibm.com, phone: +1 (978) 899-4797