[Bug tree-optimization/71437] [7 regression] Performance regression after r235817

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71437

--- Comment #16 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 3 Mar 2017, law at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71437
> 
> Jeffrey A. Law <law at redhat dot com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|NEW                         |ASSIGNED
>            Assignee|unassigned at gcc dot gnu.org      |law at redhat dot com
> 
> --- Comment #15 from Jeffrey A. Law <law at redhat dot com> ---
> So what looks real promising here.
> 
> 1. Pull the "handle_dominating_asserts" bits out of tree-ssa-threadedge and
> into tree-vrp.c.  They really should have been there all along.
> 
> 2. Improve DOM's handling of BIT_AND_EXPR/BIT_IOR_EXPR to avoid a couple minor
> regressions due to #1.
> 
> 3. Push some common code from tree-vrp.c/tree-ssa-dom.c into
> tree-ssa-threadedge.c.
> 
> 4. Change the random walk order for threading in tree-vrp.c to a domwalk

I've experimented (not very thoroughly though) with doing the threading
during substitute_and_fold via the vrp_fold_stmt callback which is now
invoked from a domwalk.

> 5. Record data from ASSERT_EXPRs during threading domwalk
> 
> 6. Query the expression hash table in simplify_stmt_for_jump_threading

That said, eventually organizing the non-backward threading as a
domwalk that uses callbacks to record data / simplify stmts so that it
can be used from VRP but also maybe from FRE or other passes that have
a useful lattice would be nice.

Not sure if all this is appropriate for GCC 7 though.