This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/50067] [4.7 Regression] Wrong code with -fpredictive-commoning


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

--- Comment #9 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-19 12:00:11 UTC ---
I think the element sizes of the access functions need to be reflected in
the base object, which we require to be operand_equal_p to any other
base to which we compare our access functions.  I'm not yet 100%
convinced that is enough though (if you view two same-shaped two-dimensional
slices from a 3d array, for example, (int (*)[16][16])&a[i][j][k] and
(int (*)[16][16])&a[l][m][n] and index them with [p][q] it should be
possible to choose i,j,k,l,m,n so that data-dependence analysis thinks
they do not overlap while they do - well, hopefully not ;)).

I'm checking what regressions it will cause to remove

  if (TREE_CODE (ref) == MEM_REF
      && TREE_CODE (TREE_OPERAND (ref, 0)) == ADDR_EXPR
      && integer_zerop (TREE_OPERAND (ref, 1)))
    ref = TREE_OPERAND (TREE_OPERAND (ref, 0), 0);

which should "fix" this part for the particular case of an outermost-only
mem-ref (that's the case where it doesn't help too much anyway, and
moving it to a more useful place creates even more issues, see comment #8).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]