[Bug tree-optimization/110891] [14 Regression] Dead Code Elimination Regression since r14-2674-gd0de3bf9175

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110891

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
I didn't anticipate the trick triggering with FRE but we have

Value numbering stmt = _6 = _5 | 64;
Setting value number of _6 to _6 (changed)
...
Value numbering stmt = _9 = _8 & 5;
Setting value number of _9 to _9 (changed)
...
Replaced a with _6 in all uses of _8 = a;
Applying pattern match.pd:184, gimple-match-10.cc:6142
Applying pattern match.pd:1962, gimple-match-6.cc:16850
gimple_simplified to _10 = _5 & 5;
_9 = _10;

that's the old issue that when we are recursively simplifying pattern
results like

  (bit_ior (bit_and @0 @2) (bit_and! @1 @2)))

we need to push operands, but when any outer operation simplifies
away we can't (or rather do not) pop them again (also when asked
to never push we'd fail the pattern before trying to simplify
the outer operation).  That can then result in such stray copies
to appear.

So the first IL difference is

--- a/t.c.114t.fre3     2023-08-04 09:22:55.380428835 +0200
+++ b/t.c.114t.fre3     2023-08-04 09:21:50.455470894 +0200
@@ -159,7 +159,7 @@
   a = _6;
   _10 = _5 & 5;
   _9 = _10;
-  a = _9;
+  a = _10;
   return 0;

 }

but that vanishes in copyprop1.  ifcombine then gets different SSA names
assigned which means different association of bitwise or operations.  For
some reason this causes the divergence in DOM2.

After copyprop2 we have

-FREE_SSANAMES: 12, 21, 3, 4, 7, 16, 15, 19, 22, 26, 17, 27, 13, 6, 20, 25, 8,
18, 24, 9, 
+FREE_SSANAMES: 12, 21, 3, 4, 7, 16, 15, 19, 22, 26, 17, 27, 9, 13, 6, 20, 25,
8, 18, 24, 

so the same SSA names are in the freelist but as that is unordered we pick
different names when re-using.

In the DOM2 pass you can see that ranger behaves slightly different when
processing operands in different order for commutative operations like
bitwise or in this case, that leads to the observed difference in threading.

Tracing ranger reveals too many differences, in the end I'd say "bad luck",
but maybe ranger folks want to investigate as well?

I'm not convinced we need to sort FREE_SSANAMES, solving the slightly
imperfect simplification for match would be nice.