On Mon, Nov 14, 2016 at 04:57:58PM +0000, Andrew Stubbs wrote:
> The testcase powerpc/fusion3.c causes an ICE when compiled with
> -msoft-float.
>
> The key line in the testcase looks fairly harmless:
>
> void fusion_float_write (float *p, float f){ p[LARGE] = f; }
LARGE is large enough that it won't fit in the offset field of a single
instruction.
> The error message look like this:
>
> .../gcc.target/powerpc/fusion3.c: In function 'fusion_float_write':
> .../gcc.target/powerpc/fusion3.c:12:1: error: unrecognizable insn:
> (insn 18 4 14 2 (parallel [
> (set (mem:SF (plus:SI (plus:SI (reg:SI 3 3 [ p ])
> (const_int 327680 [0x50000]))
> (const_int -29420 [0xffffffffffff8d14])) [1
> MEM[(float *)p_1(D) + 298260B]+0 S4 A32])
> (unspec:SF [
> (reg:SF 4 4 [ f ])
> ] UNSPEC_FUSION_P9))
> (clobber (reg/f:SI 3 3 [157]))
> ])
> "/scratch/astubbs/fsf/src/gcc-mainline/gcc/testsuite/gcc.target/powerpc/fusion3.c":12
> -1
> (nil))
When I wrote the basic fusion stuff, I was assuming nobody would do
-msoft-float -mcpu=power7. By the time the code had been written, the
soft-float libraries were no longer being built on the 64-bit Linux systems,
due to the Linux distributions dropping support for them.
However, while we can make this particular failure go away by making
powerpc_p9vector_ok (and probably some of the other targets needing VSX
features) false if -msoft-float it is still a problem, since SFmode can go in
GPRs.
This is the same basic failure (PR 78101) that I saw in building the next
generation of the Spec benchmark suite, except that it is a DFmode instead of
SFmode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78101
Both are trying to store a value from a GPR
> Basically, the problem is that the peephole optimization tries to
> create a Power9 Fusion instruction, but those do not support SF
> values in integer registers (AFAICT).
>
> So, presumably, I need to adjust either the predicate or the
> condition of the peephole rules.
Now, that I have a little time, I can look into this, to at least make
predicate and peepholes match. There is some other stuff (support for the new
load/store that were added to the compiler after that we should also tackle).
--
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
