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. It only shows up on
a little endian system on a type that does REG+REG addressing. IBM extended
double does not allow REG+REG addressing, so it wasn't an issue for that. But
with GLIBC starting to test -mabi=ieeelongdouble, it showed up.
I believe when I worked on it, we were mostly big endian, and the IEEE stuff
wasn't yet completely solid, so it was a thinko on my part.
I did the memory optimization to GPR and avoid the direct move because it is
used frequently in the GLIBC math library (and direct move on power8 being on
the slow side).
--
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
