[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

["law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65242

--- Comment #6 from Jeffrey A. Law <law at redhat dot com> ---
So I think two things are coming into play with reproducing these issues. 
First an inaccurate trunk version #.  r221042 is not a trunk commit.  I was
able to reproduce with r221041 which is a trunk commit.  Odds are Matthias
typo'd.

Second, these issues are highly dependent upon reloads actions which are known
to be notoriously difficult to predict and are easily perturbed.

So using r221041 or d21bee29dffb3724605183d17983dfc9f0ee6f21 for the GIT folks,
I was able to reproduce with the original testcase without problems.

There's a few key insns in play here.  The most important (from the IRA dump)
is:

(insn 32 33 128 3 (set (mem/f:DI (plus:DI (reg/f:DI 203 [ this ])
                (const_int 9 [0x9])) [6 this_1(D)->MissFile+0 S8 A8])
        (reg/f:DI 264)) j.C:84 467 {*movdi_internal64}
     (nil))


r203 will get a suitable hard register (r25).  r264 will not.  r264 is set via:

(insn 26 18 17 2 (set (reg/f:DI 264)
        (plus:DI (reg/f:DI 113 sfp)
            (const_int 51 [0x33]))) j.C:83 81 {*adddi3}
     (expr_list:REG_EQUIV (plus:DI (reg/f:DI 113 sfp)
            (const_int 51 [0x33]))
        (nil)))

I'm guessing sfp is a soft frame pointer or some-such eliminable register. 
Anyway, the REG_EQUIV note for r264 gets shoved into insn 32 resulting in:

(insn 32 33 128 3 (set (mem/f:DI (plus:DI (reg/f:DI 25 25 [orig:203 this ]
[203])
                (const_int 9 [0x9])) [6 this_1(D)->MissFile+0 S8 A8])
        (plus:DI (reg/f:DI 1 1)
            (const_int 51 [0x33]))) j.C:84 467 {*movdi_internal64}
     (nil))


We record the following reloads:

Reload 0: BASE_REGS, RELOAD_FOR_OPADDR_ADDR (opnum = 0), optional, can't
combine, secondary_reload_p
Reload 1: GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0), optional, can't
combine, secondary_reload_p
        secondary_out_reload = 0

        secondary_out_icode = reload_di_store
Reload 2: reload_out (DI) = (mem/f:DI (plus:DI (reg/f:DI 25 25 [orig:203 this ]
[203])
                                                        (const_int 9 [0x9])) [6
this_1(D)->MissFile+0 S8 A8])
        NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
        reload_out_reg: (mem/f:DI (plus:DI (reg/f:DI 25 25 [orig:203 this ]
[203])
                                                        (const_int 9 [0x9])) [6
this_1(D)->MissFile+0 S8 A8])
        secondary_out_reload = 1

Reload 3: reload_in (DI) = (plus:DI (reg/f:DI 1 1)
                                                    (mem/u/c:DI (unspec:DI [
                                                               
(symbol_ref/u:DI ("*.LC4") [flags 0x2])
                                                                (reg:DI 2 2)
                                                            ] UNSPEC_TOCREL)
[13  S8 A64]))
        FLOAT_REGS, RELOAD_FOR_INPUT (opnum = 1), can't combine
        reload_in_reg: (plus:DI (reg/f:DI 1 1)
                                                    (const_int 51 [0x33]))

Ugh.  So many bad things happening here I want to cry.  But I'll focus on
reload #3, note FLOAT_REGS.

In gen_add2_insn we have:
(gdb) p debug_rtx (x)
(reg:DI 32 0)
$107 = void
(gdb) p debug_rtx (y)
(mem/u/c:DI (unspec:DI [
            (symbol_ref/u:DI ("*.LC4") [flags 0x2])
            (reg:DI 2 2)
        ] UNSPEC_TOCREL) [13  S8 A64])
$108 = void

Note the register used for X.  This is a direct result of FLOAT_REGS as the
class for reload #3.

So going to the appropriate insn in the MD file we have:

(define_insn "*movdi_internal64"
  [(set (match_operand:DI 0 "nonimmediate_operand"
"=Y,r,r,r,r,r,?m,?*d,?*d,r,*h,*h,r,?*wg,r,?*wj,?*wi")
        (match_operand:DI 1 "input_operand"
"r,Y,r,I,L,nF,d,m,d,*h,r,0,*wg,r,*wj,r,O"))]

Note carefully the constraints for alternative #7.  op0  is "?m" and op1 is
"d".  

The odd offset in the address computation for operand0 causes mem_operand_opr
not to match and thus we ultimately target alternative #7.  And "d" happens to
be FP regs for double values, presumably FLOAT_REGS.  And ultimately this
causes the ICE when we try to realize the recorded reloads.

That seems a particularly bad alternative to select.  One could easily argue
the constraint for operand 0, alterantive 7 should be "!m".  In fact, if I do
that, the test passes and a peek at the reloads we generate for the
problematical insn look much better.

I'm far from a expert in the PPC backend and not confident enough to propose
this patch and find other instances that might need similar updates.  But
perhaps this saves someone else some analysis time.