[Bug tree-optimization/29333] Jump threading getting in the way of PHI-OPT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29333
--- Comment #10 from Andrew Pinski ---
(In reply to rsand...@gcc.gnu.org from comment #8)
> This may be worth filing as another PR (let me know if you
> think I should), but another case of VRP stymieing phiopt is:
>
> void bar (int);
> void
> foo (int a, int b)
> {
> if (!b)
> bar (1);
> else
> {
> int c;
> if (a)
> c = a;
> else
> c = 0;
> if (c == b)
> bar (2);
> }
> }
This was testcase was fixed on trunk by a combo of patches to tree-ssa-phiopt.c
and match.pd (r12-2041, r12-2040, r12-2039, and r12-1152 [there might have been
a few more required which I missed]) which allows early phiopt to change if (a)
c = a else c = 0; to just c = a.
[Bug tree-optimization/29333] Jump threading getting in the way of PHI-OPT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29333 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #9 from Andrew Pinski --- This actually has been fixed fully since r9-3606.
[Bug tree-optimization/29333] Jump threading getting in the way of PHI-OPT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29333
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #8 from rsandifo at gcc dot gnu.org
---
This may be worth filing as another PR (let me know if you
think I should), but another case of VRP stymieing phiopt is:
void bar (int);
void
foo (int a, int b)
{
if (!b)
bar (1);
else
{
int c;
if (a)
c = a;
else
c = 0;
if (c == b)
bar (2);
}
}
Before vrp1 we have:
[100.0%]:
if (b_3(D) == 0)
goto ; [29.6%]
else
goto ; [70.4%]
[29.6%]:
bar (1);
goto ; [100.0%]
[70.4%]:
if (a_4(D) != 0)
goto ; [50.0%]
else
goto ; [50.0%]
[35.2%]:
[70.4%]:
# c_1 = PHI
if (c_1 == b_3(D))
goto ; [22.9%]
else
goto ; [77.0%]
[16.2%]:
bar (2);
[100.0%]:
return;
phiopt would tell that c_1 is equal to a_4,
and after making that substitution, cfgcleanup
would remove blocks 4 and 5, leaving two comparisons
rather than three.
However, VRP runs first and threads 4->5 to 4->8,
giving:
[100.0%]:
if (b_3(D) == 0)
goto ; [29.6%]
else
goto ; [70.4%]
[29.6%]:
bar (1);
goto ; [100.0%]
[70.4%]:
if (a_4(D) != 0)
goto ; [50.0%]
else
goto ; [50.0%]
[35.2%]:
# c_1 = PHI
if (c_1 == b_3(D))
goto ; [45.9%]
else
goto ; [54.1%]
[16.2%]:
bar (2);
[100.0%]:
return;
[35.2%]:
# c_11 = PHI <0(4)>
goto ; [100.0%]
We never "recover" from that and so the three comparisons
survive into the final output.
Removing the first !b comparison leaves no jump threading
opportunities, so phiopt kicks in as expected.
This is a cut-down version of what happens with things like
the safe_as_a calls in NEXT_INSN. E.g. in the basic-block
iterator:
#define FOR_BB_INSNS(BB, INSN) \
for ((INSN) = BB_HEAD (BB); \
(INSN) && (INSN) != NEXT_INSN (BB_END (BB)); \
(INSN) = NEXT_INSN (INSN))
we never get rid of the p null test in:
template
inline T
safe_as_a (U *p)
{
if (p)
{
gcc_checking_assert (is_a (p));
return is_a_helper ::cast (p);
}
else
return NULL;
}
even though in release builds the function should
reduce to "return p".
[Bug tree-optimization/29333] Jump threading getting in the way of PHI-OPT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29333 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-23 10:25:20 UTC --- (In reply to comment #6) (In reply to comment #5) This is the patch which I am testing: I Have a slightly different one since we should do a few more things before the mergephi and also we ccannot remove the first mergephi as that causes vpr to lose some optimizations. I think it makes sense to do mergephi before phiopt. mergephi should not be required for VRP - can you file a bug with a testcase?
[Bug tree-optimization/29333] Jump threading getting in the way of PHI-OPT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29333 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-22 22:24:43 UTC --- (In reply to comment #5) This is the patch which I am testing: I Have a slightly different one since we should do a few more things before the mergephi and also we ccannot remove the first mergephi as that causes vpr to lose some optimizations.
[Bug tree-optimization/29333] Jump threading getting in the way of PHI-OPT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29333 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug tree-optimization/29333] Jump threading getting in the way of PHI-OPT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29333 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-22 00:47:00 UTC --- This is the patch which I am testing: Index: gcc/passes.c === --- gcc/passes.c(revision 183381) +++ gcc/passes.c(working copy) @@ -1300,11 +1300,11 @@ init_optimization_passes (void) NEXT_PASS (pass_phiprop); NEXT_PASS (pass_fre); NEXT_PASS (pass_copy_prop); - NEXT_PASS (pass_merge_phi); NEXT_PASS (pass_vrp); NEXT_PASS (pass_dce); NEXT_PASS (pass_cselim); NEXT_PASS (pass_tree_ifcombine); + NEXT_PASS (pass_merge_phi); NEXT_PASS (pass_phiopt); NEXT_PASS (pass_tail_recursion); NEXT_PASS (pass_ch); @@ -1401,6 +1401,7 @@ init_optimization_passes (void) NEXT_PASS (pass_late_warn_uninitialized); NEXT_PASS (pass_dse); NEXT_PASS (pass_forwprop); + NEXT_PASS (pass_merge_phi); NEXT_PASS (pass_phiopt); NEXT_PASS (pass_fold_builtins); NEXT_PASS (pass_optimize_widening_mul);
[Bug tree-optimization/29333] Jump threading getting in the way of PHI-OPT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29333 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org | AssignedTo|unassigned at gcc dot |pinskia at gcc dot gnu.org |gnu.org | --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-21 07:28:41 UTC --- If we do a merge_phi before the phiopt we will find it correctly. I have a few patches which adds another merge_phi right before the last phiopt and adds one right before the first phiopt.
[Bug tree-optimization/29333] Jump threading getting in the way of PHI-OPT
--- Comment #3 from roberto dot costa at st dot com 2006-10-05 08:15 --- I tested what happens if the first PHI-OPT pass is moved right before the first VRP pass in gcc/passes.c It looks like PHI-OPT should be run both before and after VRP and DOM. The example reported shows that, when PHI-OPT is run after VRP and DOM, it misses some MAX_EXPR and MIN_EXPR generation. gcc/testsuite/gcc.dg/tree-ssa/phi-opt-5.c shows that, when PHI-OPT anticipates VRP and DOM, it misses some MAX_EXPR and MIN_EXPR generation as well. Should an additional PHI-OPT pass be added before VRP and DOM? (In this case, a few testsuite examples should also be changed in order to consider what happens after PHI-OPT2 instead of PHI-OPT1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29333
[Bug tree-optimization/29333] Jump threading getting in the way of PHI-OPT
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-03 16:11 --- Actually this is a case where jump threading gets in the way of PHI-OPT. Really PHI-OPT should be put before VRP and DOM, I don't know why it was not. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-03 16:11:22 date|| Summary|Generation of MAX_EXPRs and |Jump threading getting in |MIN_EXPRs missed by phiopt |the way of PHI-OPT http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29333
