https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70032
--- Comment #2 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> Note the very first "cleanup" would be to rip out all value numbering use
> from
> the current implementation and make the pass properly separate. Now that
> FRE/PRE do full copy/constant propagation valueization shouldn't be necessary
> any more. And the special VN hacks for tail-merging could be removed
> obviously.
I did an experiment and implemented vn_valueize as the identity function in
tree-ssa-tail-merge.c.
The result with my tail-merge test script is:
...
FAIL: gcc.dg/pr51879.c scan-tree-dump-times pre "bar \\(" 1
FAIL: gcc.dg/pr51879-3.c scan-tree-dump-times pre "bar \\(" 1
FAIL: gcc.dg/pr43864-3.c scan-tree-dump-times pre "(?n)_.*\\+.*_" 1
FAIL: gcc.dg/pr43864-3.c scan-tree-dump-times pre "if " 0
FAIL: gcc.dg/pr43864-4.c scan-tree-dump-times pre "(?n)_.*-.*_" 2
FAIL: gcc.dg/pr43864-4.c scan-tree-dump-times pre "(?n)_.*\\+.*_" 1
FAIL: gcc.dg/pr43864-4.c scan-tree-dump-times pre "if " 0
FAIL: gcc.dg/pr51879-6.c scan-tree-dump-times pre "bar \\(" 1
FAIL: gcc.dg/pr43864-2.c scan-tree-dump-times pre "(?n)_.*\\+.*_" 1
FAIL: gcc.dg/pr43864-2.c scan-tree-dump-times pre "if " 0
FAIL: gcc.dg/pr51879-16.c scan-tree-dump-times pre "foo \\(" 1
FAIL: gcc.dg/pr51879-16.c scan-tree-dump-times pre "foo2 \\(" 1
FAIL: gcc.dg/pr51879-2.c scan-tree-dump-times pre "bar \\(" 1
FAIL: gcc.dg/pr51879-2.c scan-tree-dump-times pre "baz \\(" 1
FAIL: gcc.dg/pr51879-18.c scan-tree-dump-times pre "foo \\(" 1
...
Looking at the first failure, gcc.dg/pr51879.c, the representation at optimized
looks like:
...
foo (int y)
{
int a;
<bb 2>:
if (y_3(D) == 6)
goto <bb 3>;
else
goto <bb 4>;
<bb 3>:
# .MEM_5 = VDEF <.MEM_4(D)>
a_6 = bar (7);
goto <bb 5>;
<bb 4>:
# .MEM_7 = VDEF <.MEM_4(D)>
a_8 = bar (7);
<bb 5>:
# a_1 = PHI <a_6(3), a_8(4)>
# .MEM_2 = PHI <.MEM_5(3), .MEM_7(4)>
# .MEM_9 = VDEF <.MEM_2>
baz (a_1); [tail call]
# VUSE <.MEM_9>
return;
}
...
Tail-merge can't know that a_6 and a_8 are equally valued unless it uses value
numbering, and no other optimization seems to merge the two calls by moving
them up to bb2 (and in the general case, that's not necessary possible either).
Concluding, atm value numbering seems to be necessary at least for this kind of
examples.
