Re: [PATCH/RFC] Make loop-header-copying more aggressive, rerun before tree-if-conversion

[Jeff Law <law@redhat.com>]

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