Commit Message

This is patch #4 in the kit for solving 71437. This turns the random
walk of edges for threading from VRP into a dominator walk. It became
clear very quickly in that work that DOM and VRP were going to have
duplicated code with this change. That duplicated code was refactored
and pushed down into the threading module. So the patch looks much
larger than it actually is.
As part of using a domwalk for threading in VRP, we also allocate and
use an available expression table. Knowing that we always have an
expression table allows for some light cleanups in the threading code.
The setup/teardown of data structures for threading gets cleaned up ever
so slightly here as well.
Bootstrapped and regression tested on top of patches #1-#3 of this kit
on x86-64-linux-gnu and ppc64le-linux-gnu. I'll be installing it
momentarily.
Jeff
PR tree-optimization/71437
* tree-ssa-dom.c (dom_opt_dom_walker): Remove thread_across_edge
member function. Implementation moved into after_dom_children
member function and into the threader's thread_outgoing_edges
function.
(dom_opt_dom_walker::after_dom_children): Simplify by moving
some code into new thread_outgoing_edges.
* tree-ssa-threadedge.c (thread_across_edge): Make static and simplify
definition. Simplify marker handling (do it here). Assume we always
have the available expression and the const/copies tables.
(thread_outgoing_edges): New function extracted from tree-ssa-dom.c
and tree-vrp.c
* tree-ssa-threadedge.h (thread_outgoing_edges): Declare.
* tree-vrp.c (equiv_stack): No longer file scoped.
(vrp_dom_walker): New class.
(vrp_dom_walker::before_dom_children): New member function.
(vrp_dom_walker::after_dom_children): Likewise.
(identify_jump_threads): Setup domwalker. Use it rather than
walking edges in a random order by hand. Simplify setup/finalization.
(finalize_jump_threads): Remove.
(vrp_finalize): Do not call identify_jump_threads here.
(execute_vrp): Do it here instead and call thread_through_all_blocks
here too.

On 03/17/2017 06:38 AM, Trevor Saunders wrote:
> On Thu, Mar 16, 2017 at 01:17:13PM -0600, Jeff Law wrote:>> +thread_outgoing_edges (basic_block bb, gcond *dummy_cond,>> + class const_and_copies *const_and_copies,>> + class avail_exprs_stack *avail_exprs_stack,>> nit picking, but what's the point in the class keyword here?
Habit :-) There's probably a ton of this kind of thing in my code. I'd
like to defer cleaning that up until gcc-8.
>>> + tree (*simplify) (gimple *, gimple *,>> + class avail_exprs_stack *,>> + basic_block))>> this could just be pfn_simplify right?
Yes. I fixed one of these, I wouldn't be surprised if there's more.
>>> + const_and_copies *equiv_stack = new const_and_copies ();>>>> + hash_table<expr_elt_hasher> *avail_exprs>> + = new hash_table<expr_elt_hasher> (1024);>> + avail_exprs_stack *avail_exprs_stack>> + = new class avail_exprs_stack (avail_exprs);>> None of these ever live passed the end of the function right? so why not> put the objects on the stack?
Oversight. The equivalency stack was original live at the end of the
function, but that's one of the things I changed. This should be fixed
for gcc-7. I'll take care of it later today.
>>> delete equiv_stack;>> + delete avail_exprs_stack;>> this misses cleaning up the hash table right? Though of course its all> unneeded if these objects are on the stack.
Right. I'll address this stuff in a follow-up later today.
>> Hoep that's useful.
Of course. Feedback is always appreciated.
jeff