[Bug tree-optimization/103221] evrp removes |SIGN but does not propagate the ssa name

2022-01-12 Thread amacleod at redhat dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103221

--- Comment #7 from Andrew Macleod  ---
We probably do need to revisit some pass ordering.  I hope to do even less
propagation within the VRPs next release, so I would expect running copyprop
afterwards would be worthwhile.

[Bug tree-optimization/103221] evrp removes |SIGN but does not propagate the ssa name

2022-01-12 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103221

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |WONTFIX

--- Comment #6 from Andrew Pinski  ---
This bug was asking explictly for evpr to do that. So closing as won't fix
then.
The reasoning why I filed this bug is because between evrp and phiopt1 there is
not a copy prop pass.  The next copy prop pass is not until after inlining so
we might not inline as much either. So either we need to reorder some passes
around or add a copy prop pass sooner.

[Bug tree-optimization/103221] evrp removes |SIGN but does not propagate the ssa name

2022-01-12 Thread amacleod at redhat dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103221

Andrew Macleod  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #5 from Andrew Macleod  ---
We perform this optimization in appropriate places.

EVRP uses ranges to remove the | -128 leaving the statement as a copy.

Although we could then propagate the copy into the PHI node, I think we should
leave that to the copy propagation and PHIOPT passes, as we could also make
poor decisions since we are doing it with no context. 

EVRP is enabling the other passes to do their job, and GCC turns this into
"return a" as expected.

[Bug tree-optimization/103221] evrp removes |SIGN but does not propagate the ssa name

2021-12-25 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103221

Andrew Pinski  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #4 from Andrew Pinski  ---
*** Bug 77893 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/103221] evrp removes |SIGN but does not propagate the ssa name

2021-11-25 Thread amacleod at redhat dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103221

--- Comment #3 from Andrew Macleod  ---
And BTW, we do this optimization, just not completely in evrp.  EVRP removes
the extraneous | -128 since that is a range related action.

Constant propagation handles the propagation of the copy into the PHI, I'm not
sure we also need to do it in a VRP pass.

[Bug tree-optimization/103221] evrp removes |SIGN but does not propagate the ssa name

2021-11-23 Thread amacleod at redhat dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103221

Andrew Macleod  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #2 from Andrew Macleod  ---
I can tweak it so that we do register the equivalence with ranger by
reprocessing statements after a successful simplify or fold:

=== BB 3 
a_2(D)  signed char [-INF, -1]
Equivalence set : [a_2(D), v_4]
 :
v_4 = a_2(D);

v_4 : signed char [-INF, -1]

=== BB 4 
 :
# v_1 = PHI 

but it doesn't buy us much on its own.

Later passes propagate a_2 into the PHI and then fold the PHI into a copy
regardless.

We could in theory do that in EVRP too, but it seems like something copy
propagation or PHI-opt would handle more naturally.  The arguments can come
from an arbitrary list of equivalences and yet resolve to the same value... but
we need to pick the right one.  

That said, its probably worth getting the equivalence added because that could
be useful in other ways too.

[Bug tree-optimization/103221] evrp removes |SIGN but does not propagate the ssa name

2021-11-15 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103221

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-15
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
IIRC this is simplify_stmt_using_ranges not being applied during propagation
and thus the copy not being recorded.  At elimination time we are not recording
new equivalences.