On 06/19/2015 11:38 AM, Alan Lawrence wrote:
Jeff Law wrote:
On 05/22/2015 09:42 AM, Alan Lawrence wrote:
This patch does so (and makes slightly less conservative, to tackle the
example above). I found I had to make this a separate pass, so that the
phi nodes were cleaned up at the end of the pass before running
tree_if_conversion.
What PHI node cleanup needs to be done? I don't doubt something's
needed, but would like to understand the cleanup -- depending on what
needs to be done, it may be the case that we can cleanup on-the-fly or
it may point at a general issue we should be resolving prior to
running tree_if_conversion.
If I change pass_ch_vect to return 0 rather than TODO_update_cfg, my
testcase gives:
Thanks. Does running the phi-only propagator after the loop header
copying help? At first glance it would seem that it ought to propagate
the values of those degenerate PHIs then eliminate those PHIs.
It was written to cleanup after jump threading which has a tendency to
create very similar code to what you've shown below and to do so very
quickly.
/* A very simple pass to eliminate degenerate PHI nodes from the
IL. This is meant to be fast enough to be able to be run several
times in the optimization pipeline.
Certain optimizations, particularly those which duplicate blocks
or remove edges from the CFG can create or expose PHIs which are
trivial copies or constant initializations.
While we could pick up these optimizations in DOM or with the
combination of copy-prop and CCP, those solutions are far too
heavy-weight for our needs.
This implementation has two phases so that we can efficiently
eliminate the first order degenerate PHIs and second order
degenerate PHIs.
The first phase performs a dominator walk to identify and eliminate
the vast majority of the degenerate PHIs. When a degenerate PHI
is identified and eliminated any affected statements or PHIs
are put on a worklist.
The second phase eliminates degenerate PHIs and trivial copies
or constant initializations using the worklist. This is how we
pick up the secondary optimization opportunities with minimal
cost. */
I agree this isn't (/cannot be) totally definitive, so if you are not
sufficiently reassured - would you be if I called loop_optimizer_init
(LOOPS_NORMAL | LOOPS_HAVE_RECORDED_EXITS) at the end of pass_ch_vect,
redoing the setup done in pass_tree_loop_init::execute?
As I mentioned, I didn't have anything specific in mind, just a general
concern. No way to be totally definitive here. I think you've done
suitable due diligence.
Patch v2 at https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01355.html .
Thanks. It's in the queue again. Two weeks of PTO has made that queue
much deeper than I'd like, but I'm making progress :-)
jeff
