[PATCH], Fix PR target/pr83862: Fix PowerPC long double signbit with -mabi=ieeelongdouble

Michael Meissner meissner@linux.vnet.ibm.com
Thu Jan 18 19:31:00 GMT 2018


On Thu, Jan 18, 2018 at 12:39:05PM -0600, Segher Boessenkool wrote:
> On Wed, Jan 17, 2018 at 06:40:12PM -0500, Michael Meissner wrote:
> > On Wed, Jan 17, 2018 at 04:09:57PM -0600, Segher Boessenkool wrote:
> > > On Tue, Jan 16, 2018 at 10:55:43PM -0500, Michael Meissner wrote:
> > > > PR target/83862 pointed out a problem I put into the 128-bit floating point
> > > > type signbit optimization.  The issue is we want to avoid doing a load to a
> > > > floating point/vector register and then a direct move to do signbit, so we
> > > > change the load to load the upper 64-bits of the floating point value to get
> > > > the sign bit.  Unfortunately, if the type is IEEE 128-bit and memory is
> > > > addressed with an indexed address on a little endian system, it generates an
> > > > illegal address and generates an internal compiler error.
> > > 
> > > So all this is caused by these splitters running after reload.  Why do
> > > we have to do that?  Do we?  We should be able to just change it to a
> > > subreg and shift, early already?
> > 
> > The part that is failing is trying to optimize the case:
> > 
> > 	x = signbit (*p)
> > 
> > Doing the code with just registers means that you will get:
> > 
> > 	vr = load *p
> > 	gr = diret move from vr
> > 	shift
> > 
> > With the optimization you get:
> > 
> > 	gr = 'upper' word
> > 	shift
> > 
> > If the address is:
> > 
> > 	base + index
> > 
> > In little endian, the compiler tried to generate:
> > 
> > 	(base + index) + 8
> > 
> > And it didn't have a temporary register to put base+index.
> 
> Yes, but you won't have this problem if you do this before RA.  Is there
> any good reason to do it only after RA?

Yes you will, because it is a memory address not a register.

> If you do it before RA you immediately get
> 
> 	some_di = load upper from *p
> 	shift
> 
> just as you want (and things might even be optimised further).

And in my experience, splitting such loads and changing the type before RA,
often times leads to error.

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



More information about the Gcc-patches mailing list