[PATCH][PPC] Fix ICE using power9 with soft-float

[Michael Meissner]

On Tue, Nov 15, 2016 at 09:11:56PM +0000, Andrew Stubbs wrote:
> On 15/11/16 21:06, Michael Meissner wrote:
> >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).
> 
> I've been investigating this today, and I've found that the insn
> does not match because the "fusion_addis_mem_combo_store" predicate
> requires TARGET_SF_FPR is true, which in turn requires
> TARGET_HARD_FLOAT is true.
> 
> So basically the fusion stuff is disabled in soft-float mode
> regardless of where the value is stored.
> 
> Anyway, I'm at end-of-day now, so let me know if you come up with anything.

Yeah, SFmode and DFmode should not have the TARGET_{S,D}F_FPR checks.

But a secondary problem is the early clobber in the match_scratch.

Before the peephole2 we have:

(insn 7 4 8 2 (set (reg/f:DI 3 3 [157])
        (plus:DI (reg:DI 3 3 [ p ])
            (const_int 327680 [0x50000]))) "fusion3.c":12 75 {*adddi3}
     (nil))

(insn 8 7 14 2 (set (mem:SF (plus:DI (reg/f:DI 3 3 [157])
                (const_int -29420 [0xffffffffffff8d14])) [1 MEM[(float *)p_1(D) + 298260B]+0 S4 A32])
        (reg:SF 4 4 [ f ])) "fusion3.c":12 484 {*movsf_softfloat}
     (expr_list:REG_DEAD (reg:SF 4 4 [ f ])
        (expr_list:REG_DEAD (reg/f:DI 3 3 [157])
            (nil))))

This gets combined into:

(insn 17 4 14 2 (parallel [
            (set (mem:SF (plus:DI (plus:DI (reg:DI 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:DI 3 3 [157]))
        ]) "fusion3.c":12 -1
     (nil))

where (reg:DI 3) is the base register temporary.  Since it was used as part of
the original address, the early clobber check in constrain_operands will flag
it.  This is what is causing PR 78101.  Thus there are two issues here.

In the scope of the ISA 3.0/power9 work, there is also the issue that the new
d-form load and stores should be folded into this as well.  This is due to me
doing the original power9/ISA 3.0 fusion first, and then putting it on the
shelf, and then months later working on the new address forms, and never
getting back to fusion.

As it is currently written, there was an expectation that the fusion stuff
would eventually move from being a peephole2 to being part of the addressing
handled before register allocation.  Then the secondary reload hook would call
the appropriate fusion helper function, which is why we have int_ and gpr_
fusion insn functions, each based on a separate register class.  The int_
fusion form allows SFmode/DFmode, but as you point out the combo recognizer
doesn't allow them in GPRs.

I'm not as sure that we will have the will to move fused addresses early before
register allocation, and whether we need to keep around the separate int_ and
fpr_ forms.

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