On 7/27/2021 10:21 AM, Aldy Hernandez wrote:
On 7/27/21 5:15 PM, Jeff Law wrote:
My recollection is there's also a case where the location of the
state push/pops are highly unintuitive. I always meant to put in
some sanity checking on the push/pops, then go back and bring some
sanity to that code as well. The one time I recall trying to clean
this up (without the sanity checking) I mucked it up badly -- and the
only symptom was we just started missing various jump threading
opportunities ;( Mentioning it for awareness.
Yes, I noticed that things were somewhat tricky.
For instance, the caller (DOM / VRP) can also push and pop
avails_exprs_stack/evrp/etc state, but I decided to ignore those since
the threader only cares about the threading candidates it's considering.
Well, what's interesting is that DOM needs to save state before handing
off to the threader so that it's tables aren't polluted by the
threader. I think this is where those unintuitive push/pops were -- one
operation was in DOM and the other in the threader. Ugh!
My ulterior purpose for this patch is to have a set of blocks / edges
that indicate a path, and pass those to the jump threader simplify
callback.
Right.
In doing this I also found that the edges are not the only information
denoting a path. We also have (some) blocks pushed into the
jump_thread_edge (at least the EDGE_*COPY_SRC_BLOCK ones). I will be
adding the capacity to add those in a follow-up.
Right those blocks are join points in the CFG. We don't know the static
result of the branch in the join block, but the join point may have a
successor with a conditional branch that we can thread. See:
https://gcc.gnu.org/legacy-ml/gcc-patches/2011-06/msg01190.html
A good mental model to use for this case is to imagine making a copy of
that block for each incoming edge. ie, each copy is only reachable from
one predecessor. That in turn allows jump threading to look deeper
through the CFG. If we find threadable jumps deeper in the CFG, then
we'll actually make those copies and scramble the CFG appropriately.
And yes it's been somewhat painful. What I've been doing is plugging
into the evrp use in DOM threader, and making sure that the my
follow-up changes to the path solver can simplify all the
conds/switches that the DOM/VRP threader simplifier can handle.
Ughhh, did any of this make sense? I manage to even confuse myself
while explaining it :).
Generally yes. In fact, it's forcing me to page in all kinds of things
I'd forgotten.
jeff
