https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82397
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Alexander Monakov from comment #1)
> This is because operand_equal_p is "smarter" than data_ref_compare_tree. We
> have something like
>
> A: (long)_1 + (_2 + _3)
> B: (_2 + _4) + (long)_1
> C: (_2 + _3) + (long)_1
>
> with A == C != B according to operand_equal_p (and A < B < C according to
> data_ref_compare_tree), making comparison steps like this non-transitive:
>
> if (!operand_equal_p (DR_BASE_ADDRESS (dra), DR_BASE_ADDRESS (drb), 0))
> {
> cmp = data_ref_compare_tree (DR_BASE_ADDRESS (dra),
> DR_BASE_ADDRESS (drb));
>
>
> Perhaps additive chains in compared operands should be canonicalized first
> so that if two items are equal according to operand_equal_p they're also
> guaranteed to be equal according to data_ref_compare_tree?
I think the issue is not so much the equalness (which we really like to
see!) but the recursion down to the operands with determining which
one is less depends on the order of the operands:
/* For expressions with operands, compare their operands recursively. */
for (i = TREE_OPERAND_LENGTH (t1) - 1; i >= 0; --i)
{
cmp = data_ref_compare_tree (TREE_OPERAND (t1, i),
TREE_OPERAND (t2, i));
if (cmp != 0)
return cmp;
}
for a solution we either may _not_ exploit commutativity when looking for
equalities or we need to make the above loop take into consideration
all operands and compute a result that is independent of individual
operand order (which I guess makes the comparison useless...).
Thus. Hum. The only thing we can do is to apply clever canonicalization.
