[Bug target/93974] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762

[bergner at gcc dot gnu.org]

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

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at gcc dot gnu.org,
                   |                            |wschmidt at gcc dot gnu.org

--- Comment #4 from Peter Bergner <bergner at gcc dot gnu.org> ---
I'm CCing Vlad, since I need some guidance/help for some LRA questions.

So this looks similar to PR93658, in that my patch exposed a latent bug.
However, in this case, the bugs seems to be in the LRA constraints fixup
code.

Jakub, I would normally just think reverting the 3 commits used to fix
PR93658 in GCC 8 would be the best course of action here, but if we do
that, then we're just reexposing the bug from PR93658.  But maybe that
is still preferable than applying an LRA fix (which we don't have yet)
that could affect all targets this late in the release process?  Thoughts?

So onto my findings.  After IRA, we have the following allocations and rtl:

Disposition:
    6:r121 l0   mem    5:r124 l0    33    4:r125 l0    34    0:r128 l0    14

(insn 34 (set (reg:DI 128) (const_int -32)))
...
(insn 39 (set (reg:V2DF 121 [ D.3415 ])
              (mem/c:V2DF (and:DI (plus:DI (reg/f:DI 110 sfp)
                                  (reg:DI 128))
                          (const_int -16))))
     (expr_list:REG_EQUIV (mem/c:V2DF (and:DI (plus:DI (reg/f:DI 110 sfp)
(reg:DI 128)) (const_int -16)))
       (expr_list:REG_EQUAL (mem/c:V2DF (plus:DI (reg/f:DI 110 sfp) (const_int
-32))))))
...
(insn 15 (set (reg:DF 124)
              (subreg:DF (reg:V2DF 121) 0)))
(insn 16 (set (reg:DF 125 [+8 ])
              (subreg:DF (reg:V2DF 121) 8))
     (expr_list:REG_DEAD (reg:V2DF 121)))

When LRA processes insn 15, it replaces the subreg: reg with the mem from
insn 39 and we get:

(insn 15 (set (reg:DF 124)
              (mem/c:DF (and:DI (plus:DI (plus:DI (reg/f:DI 110 sfp)
                                                  (reg:DI 128))
                                         (const_int 64 [0x40]))
                                (const_int -16)))))

This is not a valid address, so LRA in process_address(), we pass the
following address to decompose_address():

(and:DI (plus:DI (plus:DI (reg/f:DI 110 sfp)
                          (reg:DI 128))
                 (const_int 64))
        (const_int -16))

Eventually, we end up with:

(insn 56 (set (reg:DI 136)
              (plus:DI (reg/f:DI 110 sfp)
                       (const_int 64))))
(insn 57 (set (reg:DI 136)
              (plus:DI (reg:DI 136)
                       (reg:DI 128))))
(insn 58 (set (reg:DI 136)
              (and:DI (reg:DI 136)
                      (const_int -16))))
(insn 15 (set (reg:DF 124)
              (mem/c:DF (reg:DI 136))))

This isn't ideal, but looks correct.

The problem comes when we process insn 16.  It looks just like insn 15,
but its subreg is at an offset of 8.  In decompose_address(), we're
passed an address that looks like:

(plus:DI (and:DI (plus:DI (plus:DI (reg/f:DI 110 sfp)
                                   (reg:DI 128))
                          (const_int 64))
                 (const_int -16))
         (const_int 8))

Now strip_address_mutations() seems to expect seeing a "(and: ..." type
address, but it is completely confused by seeing a PLUS wrapped around
it, which is what eventually causes us to ICE in decompose_normal_address
because it doesn't look like we have a base_term or index_term type addr.

Vlad, do you have some guidance on what should be done when we see
an address like the above?  I tried hacking some changes to recognize
the extra PLUS, but ended up causing an infinite loop in LRA.
Do you have thoughts on how to fix this properly?