https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61783
Bug ID: 61783
Summary: [4.10 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c
scan-tree-dump-times dom1 "if " 2
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sch...@linux-m68k.org
CC: rguenther at suse dot de
Target: m68k-*-*
>From <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757#17>:
--- Comment #17 from Michael Matz <matz at gcc dot gnu.org> ---
The testsuite failure on m68k is indeed caused by r212352. In particular
this hunk:
@@ -1641,8 +1609,7 @@ record_equality (tree x, tree y)
long as we canonicalize on one value. */
if (is_gimple_min_invariant (y))
;
- else if (is_gimple_min_invariant (x)
- || (loop_depth_of_name (x) <= loop_depth_of_name (y)))
+ else if (is_gimple_min_invariant (x))
prev_x = x, x = y, y = prev_x, prev_x = prev_y;
else if (prev_x && is_gimple_min_invariant (prev_x))
x = y, y = prev_x, prev_x = prev_y;
The test is <=, so without loops (both SSA names being at 'depth' 0) the check
succeeds always and hence will canonicalize on x (i.e. record x as value of y).
The testcase is written so that this is the expected order for the third
if to be found trivial.
The problem doesn't happen on x86-64 because with -O1 the && condition is
rewritten into arithmetic on '&', so even though the wanted transformation
doesn't happen there are only two 'if ' statements, which is what is searched
for.
Unfortunately this is all harmless and not causing the miscompilations, it's
only a missed optimization.
FWIW, I think the canonicalization that DOM wants here should be retained
in some form (canonicalize to the value that covers a larger area). Possibly
by checking if one definition dominates the other
