http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49573
Carrot <carrot at google dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED
--- Comment #1 from Carrot <carrot at google dot com> 2011-07-08 01:46:55 UTC
---
The error is caused by some inconsistent properties. For the memory load
expression
(mem/s/f:SI (reg/v/f:SI 196 [ cache ])
in bb9, it is transp, antloc but not comp, this should never occur, since
antloc implies there is a local computation, transp implies it should also be
available at the end of the basic block, contradicting to the actual comp
result, and caused wrong code generated.
The root cause is that there are several rtl expression for (mem/s/f:SI
(reg/v/f:SI 196 [ cache ]), although they are lexically same, but with
different corresponding ssa name, alias set and ptrtype. But they are
considered same and an arbitrary one was chosen as a representative.
Then in basic block 9, the representative "(mem/s/f:SI (reg/v/f:SI 196 [ cache
]) [4 cache_31->fNext+0 S4 A32])" is used to compute transp and the local
expression "(mem/f:SI (reg/v/f:SI 196 [ cache ]) [4 MEM[(struct SkGlyphCache *
*)cache_51]+0 S4 A32])" is used to compute local comp. When these rtl
expressions are used to compute true_dependence, it get different result, and
inconsistent local pre properties.
The patch r175024 and r175023 treat rtl expressions with different MEM_ATTRS as
different expressions, so we will never get chances to use expressions with
different SSA name/alias/ptrtype to compute different pre properties for the
same expression. Thus fixed this problem.
