Hi Andrew,
Thanks for the patch and looking into this.
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.
> 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).
The peepholes do not support it, or maybe the define_insns do not either.
The machine of course will not care.
> So, presumably, I need to adjust either the predicate or the condition
> of the peephole rules.
Yes.
> The predicate used is "toc_fusion_or_p9_reg_operand", and this might be
> the root cause, but I don't know the architecture well enough to be
> sure.
This fusion is quite simple really. Offset addressing insns can only
access a 16-bit range, but instead of writing e.g.
lwz 0,0x12345678(3)
you can do
addis 4,3,0x1234
lwz 0,0x5678(4)
and the processor will execute it faster, essentially like if it was
written as the first example. See 2.1.1 in Power ISA 3.0.
> The predicate code seems to suggest that "toc_fusion", whatever
> that is, should be able to do this, but the insn produced by the
> peephole uses only UNSPEC_FUSION_P9, which does not. Perhaps this
> predicate is inappropriate for the P9 Fusion peephole, or perhaps it
> needs to be taught about this corner case?
One of those yes.
> In any case, I don't want to change the predicate without being sure
> what it does (here and elsewhere), so the attached patch solves the
> problem by changing the condition.
>
> Is this OK, or do I need to do something less blunt?
We can have floats in GPRs even without TARGET_SOFT_FLOAT, so this
does not even work? And yes this is blunt :-)
Segher
