[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