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.
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.
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.
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 :).
OK and thanks so much for cleaning this up.
NP. Thanks for reviewing them!
Aldy
