Question about how to fix PR69052

["Bin.Cheng" <amker dot cheng at gmail dot com>]

Hi,
In revision 229402, I added logic in loop-invariant.c to check if a
look invariant can be forward propagated to memory references in the
same loop; and increase loop invariant cost if the answer is no.  I
think this is a reasonable change.  Some targets like AArch64 can
benefit from it because many sp/fp related expressions can be hoisted
out of loop.
Unfortunately, it runs into problem on x86+PIC.  Given below GOT related loads:

(insn 67 66 69 9 (set (reg/f:SI 147)
        (mem/u/c:SI (plus:SI (reg:SI 87)
                (const:SI (unspec:SI [
                            (symbol_ref:SI ("out")  <var_decl
0x7fef1484af30 out>)
                        ] UNSPEC_GOT))) [3  S4 A8])) pr69052.c:39 86
{*movsi_internal}
     (nil))
(insn 69 67 70 9 (set (reg/f:SI 149)
        (plus:SI (reg:SI 87)
            (const:SI (unspec:SI [
                        (symbol_ref:SI ("ind") [flags 0x2]  <var_decl
0x7fef1484ae10 ind>)
                    ] UNSPEC_GOTOFF)))) pr69052.c:39 212 {*leasi}
     (expr_list:REG_DEAD (reg:SI 87)
        (nil)))
(insn 70 69 71 9 (set (reg:SI 150)
        (mem/u:SI (plus:SI (mult:SI (reg/v:SI 90 [ k ])
                    (const_int 4 [0x4]))
                (reg/f:SI 149)) [1 ind S4 A32])) pr69052.c:39 86
{*movsi_internal}
     (expr_list:REG_DEAD (reg/f:SI 149)
        (nil)))
(insn 71 70 72 9 (set (mem:SI (plus:SI (mult:SI (reg:SI 150)
                    (const_int 4 [0x4]))
                (reg/f:SI 147)) [1 out S4 A32])
        (reg/v:SI 89 [ result ])) pr69052.c:39 86 {*movsi_internal}
     (expr_list:REG_DEAD (reg:SI 150)
        (expr_list:REG_DEAD (reg/f:SI 147)
            (expr_list:REG_DEAD (reg/v:SI 89 [ result ])
                (nil)))))

insn 67/69 can be merged into insn 71/70 respectively in combine pass.
Problem is transformation done by combine is complex and hard to in
other passes like loop invariant.

Yuri Rumyantsev suggested we may add a hook to handle GOT related
instruction propagation specially so it won't be hoisted out.  Is a
hook at this stage sounds feasible?

Also it would be great if we can abstract an interface out of combine,
and the interface can be used in other passes checking whether
instructions can be merged or not.  I know this will be even harder
than emulation of combine behavior.

Another point is if we can do combine among different basic blocks?

Any idea on this?

Thanks,
bin