On 8/18/22 03:08, Richard Biener wrote:
The caveat is that it is only a partial solution... it will only work for
names on that stmt. if you have anything more complex, ie
if (a == 0 || b == 0) we have a seqeunce feeding the ctrl stmt..
c_1 = a == 0
c_2 = b == 0
c_3 = c_1 && c_2
if (c_3 == 0)
only the evaluation of c_3 will have the ctrl stmt as its context.. the others
will be evaluted on their own statement, and thus neither a nor b would pick
up anything from the block as they are evalauted and cached as they are
seen. unless of course we are doing a walk :-P
Hmm, but as I traced it when I do range_of_expr the context stmt I provide
will be passed down and even when processing dependences that context
will stick? But maybe it doesn't because it would mean explosion of the
cache?
But yeah, with the above restriction it would be even more useless.
Same issue as with
*p = 0;
if (..)
/ \
.. \
if (p)
here the local adjustment of 'p' in if (p) would not pick up the
p != 0 guarantee from the immediate dominator.
it certainly should. the earlier BB will have the ~[0, 0] property in
the on-exit structure, so when the range of 'p' is evaluated on the edge
to the next block, it will be adjusted. the value for on-entry of P to
that block will therefore be ~[0, 0]. Ranger does this, and the path
query code is *suppose* to.. late discussions with Aldy yesterday left
me unclear if it always does. it should. that was the entire point of
leaving the on-demand filling of the structure via immediate uses.
In the meantime,
it should be possible to take a ranger that just completed a VRP pass, and use
that as the root ranger for a threading pass immediately after.. I think there
may be some lingering issues with abnormal edges if we "re-visit" blocks which
we claim to have walked due to the way I store inferred ranges in those
block.. (the expectation being we never go back up into the block, so the
on-entry cache works like the "current def" vector in the original EVRP. I'd
have to think about that too.
Of course that would essentially do a VRP pass before each threading
which I think is a bit expensive. Also looking at how ranger works
with all its abstraction having the "old" EVRP style body walk rather
than abusing the on-demand ranger for such a walk would be a lot more
efficient for this purpose :/
No, I just meant when we do the VRP pass, rather than throw away the
fully primed ranger and its values, one could invoke the threader using
it... But I'm not sure how much extra we'd get anyway.
Meanwhile I'm leaning towards calling this a phase ordering issue
of threading + VRP, but that also means we shouldn't deliberately
try to preserve "threadings" of this kind - in fact we might want
to explicitely reject them?
we are probably going to want to visit some pass ordering.
Sure, though there's never going to be a good enough pass ordering :/
Richard.
