[Bug middle-end/24804] [3.4 Regression] Produces wrong code

[wilson at gcc dot gnu dot org]

------- Comment #4 from wilson at gcc dot gnu dot org  2005-11-29 03:39 -------
The failure happens in store_motion in gcse.c.

We have two objects on the stack with disjoint lifetimes that overlap.  They
have different MEM_EXPRS, and some of the mems also have different alias sets. 
They have different MEM_EXPRs as they are from different objects.
(insn 34 3 37 0 (set (mem/s/j:SI (plus:SI (reg/f:SI 20 frame)
                (const_int -32 [0xffffffffffffffe0])) [0 <variable>.X0+0 S4
A32\])
        (const_int 0 [0x0])) 43 {*movsi_1_nointernunit} (nil)
    (nil))
(insn 92 89 99 0 (set (mem/s/j:SI (plus:SI (reg/f:SI 20 frame)
                (const_int -32 [0xffffffffffffffe0])) [0 <variable>.X4+0 S4
A32\])
        (const_int 0 [0x0])) 43 {*movsi_1_nointernunit} (nil)
    (nil))
(insn 116 162 117 2 (set (mem/s/j:SI (plus:SI (reg/f:SI 20 frame)
                (const_int -32 [0xffffffffffffffe0])) [0 f2.X4+0 S4 A128])
        (const_int 0 [0x0])) 43 {*movsi_1_nointernunit} (nil)
    (nil))

This in itself is fairly harmless.  However, a problem occurs when we try to
keep track of mems.  We call ldst_entry which computes a hash code, which is
identical for the two mems, and then puts them into the same ls_expr structure.
 This ls_expr structure only holds one mem rtx.  Which means the aliasing info
is now wrong for the other mem rtx.  Eventually we call true_dependence with a
read for the other mem, and it decides that they can't alias because of the
differing MEM_EXPRs.

It appears that the solution here is to somehow combine the aliasing info when
putting multiple mems into a single ls_expr structure.  If we put two MEMs with
differing MEM_EXPRs into the same ls_expr structure, then we should create a
new mem with a cleared MEM_EXPR field.  Similarly, if we have two MEMs with
different alias sets, then we may need to say that they can alias anything.

There is a comment that indicates that we are deliberately ignoring the alias
sets when computing the hash codes, as this caused problems for profile
feedback directed optimization.  I haven't looked at the details here.

The testcase doesn't fail with gcc-4.0 and up, because after tree-ssa opts
there isn't anything left for the RTL gcse pass to do.  However, I believe the
bug is still there in the code, it is just very much harder to reproduce now.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24804