On 6/9/21 7:32 AM, Richard Biener wrote:
On Tue, Jun 8, 2021 at 4:31 PM Andrew MacLeod <amacl...@redhat.com> wrote:
an iteration causes a relation
to become "better" it should be updated.
do a very simplistic thing when trying to simplify downstream conditions
based on earlier ones, abusing their known-expressions hash tables
by, for example, registering (a < b) == 1, (a > b) == 0, (a == b) == 0,
(a != b) == 1 for an earlier a < b condition on the true edge. So I wonder
if this relation code can be somehow used there. In VN there's the
extra complication that it iterates, but DOM is just a DOM-walk and
the VN code also has a non-iterating mode (but not a DOM walk).
Note VN does optimistic iteration thus relations will become only "worse",
thus we somehow need to be able to remove relations we added during
the last iteration. That is, in the first iteration a if (a > b) might be
registered as a > 1 when b has (optimistic) value b but in the second
we have to make it a > b when b dropped to varying for example.
The optimistic part of VN is that it treats all edges as not executable
initially and thus it ignores values on non-executable edges in PHI
nodes.
Yeah, haven't had to do that yet. The add method currently does an
intersection with any relation it finds already present, it shouldn't be
too much work to add an alternate add routine that says "replace". In
fact, that may be also be adequate for my purposes, since typically the
second time a relation is added, it *should* be either the same, or
"better" for me. The tricky part is I think it may already include any
relation that dominates the currently location.. but that is addressable.
I'll keep an eye on this as I'm prepping the code and writing it up.
The API is for registering is pretty straightforward:
void register_relation (gimple *stmt, relation_kind k, tree op1, tree
op2);
void register_relation (edge e, relation_kind k, tree op1, tree op2);
so all you'd have to do when a < b is encountered is to register (a
LT_EXPR b) on the true edge, and (a GE_EXPR b) on the false edge. Then
any queries downstream should be reflected.
Of course the code is also used to simplify
if (a > b)
c = a != b;
but the relation oracle should be able to handle that as well I guess.
As we start using the code more, we may find we want/need a few more
wrappers around some of this so that you can transparently ask what the
RHS folds to without any ranger present, just with relations. Those'll
be fairly trivial to add...
The relation oracle is going to be directly accessible from the
get_range_query(cfun) range_query class. I'll do a big writeup when i
submit it and we should be able to make it usable in any of those places.
OK, so using this from DOM should be pretty straight-forward (you may
want to try to use it there as proof of API sanity). When it's in I'll see if
it fits (iterative) VN.
Yeah, it should be quite straightforward as part of DOM.. and should be
easy to set and query in parallel with whats there to verify its getting
the same results. Famous last words. But yes, this would be further
proof its evaluating what we expect on top of doing what EVRP did.
Slight delay while I'm sorting out some minor API issues to enable using
this without ranger right off the bat, as well as interaction with some
recent changes I made.
Andrew
