On 9/24/2021 9:46 AM, Aldy Hernandez wrote:
This patch implements the new hybrid forward threader and replaces the
embedded VRP threader with it.
But most importantly, it pulls it out of the VRP pass as we no longer need the VRP data or ASSERT_EXPRs.


With all the pieces that have gone in, the implementation of the hybrid
threader is straightforward: convert the current state into
SSA imports that the solver will understand, and let the path solver
precompute ranges and relations for the path.  After this setup is done,
we can use the range_query API to solve gimple statements in the threader.
The forward threader is now engine agnostic so there are no changes to
the threader per se.
So the big question is do we think it's going to be this clean when we try to divorce the threading from DOM?


I have put the hybrid bits in tree-ssa-threadedge.*, instead of VRP,
because they will also be used in the evrp removal of the DOM/threader,
which is my next task.
Sweet.


Most of the patch, is actually test changes.  I have gone through every
single one and verified that we're correct.  Most were trivial dump
file name changes, but others required going through the IL an
certifying that the different IL was expected.

For example, in pr59597.c, we have one less thread because the
ASSERT_EXPR was getting in the way, and making it seem like things were
not crossing loops.  The hybrid threader sees the correct representation
of the IL, and avoids threading this one case.

The final numbers are a 12.16% improvement in jump threads immediately
after VRP, and a 0.82% improvement in overall jump threads.  The
performance drop is 0.6% (plus the 1.43% hit from moving the embedded
threader into its own pass).  As I've said, I'd prefer to keep the
threader in its own pass, but if this is an issue, we can address this
with a shared ranger when VRP is replaced with an evrp instance
(upcoming).
Presumably we're also seeing a cannibalization of threads from later passes.   And just to be clear, this is good.

And the big question, is the pass running after VRP2 doing anything particularly useful?  Do we want to try and kill it now, or later?


As I mentioned in my introductory note, paths ending in MEM_REF
conditional are missing.  In reality, this didn't make a difference, as
it was so rare.  However, as a follow-up, I will distill a test and add
a suitable PR to keep us honest.
Yea, I don't think these are going to be a notable issue for the threaders that were previously run out of VRP.  I'm less sure about DOM though.


There is a one-line change to libgomp/team.c silencing a new used
uninitialized warning.  As my previous work with the threaders has
shown, warnings flare up after each improvement to jump threading.  I
expect this to be no different.  I've promised Jakub to investigate
fully, so I will analyze and add the appropriate PR for the warning
experts.
ACK.



Oh yeah, the new pass dump is called vrp-threader[12] to match each
VRP[12] pass.  However, there's no reason for it to either be named
vrp-threader, or for it to live in tree-vrp.c.

Tested on x86-64 Linux.

OK?

p.s. "Did I say 5 weeks?  My bad, I meant 5 months."

gcc/ChangeLog:

        * passes.def (pass_vrp_threader): New.
        * tree-pass.h (make_pass_vrp_threader): Add make_pass_vrp_threader.
        * tree-ssa-threadedge.c (hybrid_jt_state::register_equivs_stmt): New.
        (hybrid_jt_simplifier::hybrid_jt_simplifier): New.
        (hybrid_jt_simplifier::simplify): New.
        (hybrid_jt_simplifier::compute_ranges_from_state): New.
        * tree-ssa-threadedge.h (class hybrid_jt_state): New.
        (class hybrid_jt_simplifier): New.
        * tree-vrp.c (execute_vrp): Remove ASSERT_EXPR based jump
        threader.
        (class hybrid_threader): New.
        (hybrid_threader::hybrid_threader): New.
        (hybrid_threader::~hybrid_threader): New.
        (hybrid_threader::before_dom_children): New.
        (hybrid_threader::after_dom_children): New.
        (execute_vrp_threader): New.
        (class pass_vrp_threader): New.
        (make_pass_vrp_threader): New.

libgomp/ChangeLog:

        * team.c: Initialize start_data.
        * testsuite/libgomp.graphite/force-parallel-4.c: Adjust.
        * testsuite/libgomp.graphite/force-parallel-8.c: Adjust.

gcc/testsuite/ChangeLog:

        * gcc.dg/torture/pr55107.c: Adjust.
        * gcc.dg/tree-ssa/phi_on_compare-1.c: Adjust.
        * gcc.dg/tree-ssa/phi_on_compare-2.c: Adjust.
        * gcc.dg/tree-ssa/phi_on_compare-3.c: Adjust.
        * gcc.dg/tree-ssa/phi_on_compare-4.c: Adjust.
        * gcc.dg/tree-ssa/pr21559.c: Adjust.
        * gcc.dg/tree-ssa/pr59597.c: Adjust.
        * gcc.dg/tree-ssa/pr61839_1.c: Adjust.
        * gcc.dg/tree-ssa/pr61839_3.c: Adjust.
        * gcc.dg/tree-ssa/pr71437.c: Adjust.
        * gcc.dg/tree-ssa/ssa-dom-thread-11.c: Adjust.
        * gcc.dg/tree-ssa/ssa-dom-thread-16.c: Adjust.
        * gcc.dg/tree-ssa/ssa-dom-thread-18.c: Adjust.
        * gcc.dg/tree-ssa/ssa-dom-thread-2a.c: Adjust.
        * gcc.dg/tree-ssa/ssa-dom-thread-4.c: Adjust.
        * gcc.dg/tree-ssa/ssa-thread-14.c: Adjust.
        * gcc.dg/tree-ssa/ssa-vrp-thread-1.c: Adjust.
        * gcc.dg/tree-ssa/vrp106.c: Adjust.
        * gcc.dg/tree-ssa/vrp55.c: Adjust.
OK
jeff

Reply via email to