Re: [PATCH] Implement a context aware points-to analyzer for use in evrp.

[Andrew MacLeod <amacleod@redhat.com>]

On 6/9/21 7:32 AM, Richard Biener wrote:
> On Tue, Jun 8, 2021 at 4:31 PM Andrew MacLeod <amacleod@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