This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
- From: "matz at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 11 Jul 2014 17:47:20 +0000
- Subject: [Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
- Auto-submitted: auto-generated
- References: <bug-61757-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
--- 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