[Bug target/113255] [11/12/13/14 Regression] wrong code with -O2 -mtune=k8

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
DSE thinks the store is dead because it falls off the function.

(insn 41 40 46 4 (set (mem/c:SI (plus:DI (reg/f:DI 19 frame)
                (const_int -36 [0xffffffffffffffdc])) [2 e[1].y+0 S4 A32])
        (reg:SI 98 [ e$1$y ])) "t.c":21:9 85 {*movsi_internal}
     (expr_list:REG_DEAD (reg:SI 98 [ e$1$y ])
        (nil)))

...

(insn 64 63 68 4 (parallel [
            (set (reg:DI 131)
                (const_int 0 [0]))
            (set (reg/f:DI 129)
                (plus:DI (ashift:DI (reg:DI 131)
                        (const_int 3 [0x3]))
                    (reg/f:DI 129)))
            (set (reg/f:DI 119)
                (plus:DI (ashift:DI (reg:DI 131)
                        (const_int 3 [0x3]))
                    (reg/f:DI 119)))
            (set (mem/c:BLK (reg/f:DI 129) [1  A64])
                (mem/c:BLK (reg/f:DI 119) [1  A8]))
            (use (reg:DI 131))
        ]) "t.c":21:9 1416 {*rep_movdi_rex64}
     (expr_list:REG_UNUSED (reg:DI 131)
        (expr_list:REG_UNUSED (reg/f:DI 129)
            (expr_list:REG_UNUSED (reg/f:DI 119)
                (nil)))))

it appears to be a bit convoluted how we compute the source of the block
copy (reg/f:DI 119) and this is probably confusing "frame related" vs.
non-frame-related MEM disambiguation.

I'm unsure the above parallel is valid, isn't parallel executing stmts
in "parallel" (unspecified order)?

**scanning insn=64
  mem: (reg/f:DI 119)

   after canon_rtx address: (reg/f:DI 119)

   after cselib_expand address: (minus:DI (plus:DI (reg/f:DI 129)
        (reg/f:DI 133))
    (reg/f:DI 134))

   after canon_rtx address: (minus:DI (plus:DI (reg/f:DI 129)
        (reg/f:DI 133))
    (reg/f:DI 134))
  varying cselib base=17:1741806 offset = 0
 processing cselib load mem:(mem/c:BLK (reg/f:DI 119) [1  A8])
 processing cselib load against insn 55
removing from active insn=55 has store
 processing cselib load against insn 47
removing from active insn=47 has store
 processing cselib load against insn 41
mems_found = 0, cannot_delete = true

we're calling canon_true_dependence with

(gdb) p debug_rtx (store_info->mem)
(mem/c:SI (plus:DI (reg/f:DI 19 frame)
        (const_int -36 [0xffffffffffffffdc])) [2 e[1].y+0 S4 A32])
(gdb) p debug_rtx (mem)
(mem/c:BLK (reg/f:DI 119) [1  A8])
(gdb) p debug_rtx (mem_addr)
(minus:DI (plus:DI (value:DI 8:1741643 @0x49c8ba8/0x49b8e80)
        (value:DI 11:11 @0x49c8bf0/0x49b8f10))
    (value:DI 9:9 @0x49c8bc0/0x49b8eb0))

and find_base_term of the mem_addr is returning

(symbol_ref:DI ("g_e") [flags 0x2] <var_decl 0x7ffff7019c60 g_e>)

which is because of the weird way we compute the source address (involving
the address of the destination).  There's a very old bug about find_base_term
which tends to pick up a wrong base if multiple candidates are involved.

I can't decipher this from what expand generates but the problem lies
there (the rep_8bytes expansion).