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

Aldy Hernandez aldyh@redhat.com
Mon Jun 7 18:29:53 GMT 2021

On 6/7/21 3:30 PM, Richard Biener wrote:
> On Mon, Jun 7, 2021 at 12:10 PM Aldy Hernandez via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>> The substitute_and_fold_engine which evrp uses is expecting symbolics
>> from value_of_expr / value_on_edge / etc, which ranger does not provide.
>> In some cases, these provide important folding cues, as in the case of
>> aliases for pointers.  For example, legacy evrp may return [&foo, &foo]
>> for the value of "bar" where bar is on an edge where bar == &foo, or
>> when bar has been globally set to &foo.  This information is then used
>> by the subst & fold engine to propagate the known value of bar.
>> Currently this is a major source of discrepancies between evrp and
>> ranger.  Of the 284 cases legacy evrp is getting over ranger, 237 are
>> for pointer equality as discussed above.
>> This patch implements a context aware points-to class which
>> ranger-evrp can use to query what a pointer is currently pointing to.
>> With it, we reduce the 284 cases legacy evrp is getting to 47.
>> The API for the points-to analyzer is the following:
>> class points_to_analyzer
>> {
>> public:
>>    points_to_analyzer (gimple_ranger *r);
>>    ~points_to_analyzer ();
>>    void enter (basic_block);
>>    void leave (basic_block);
>>    void visit_stmt (gimple *stmt);
>>    tree get_points_to (tree name) const;
>> ...
>> };
>> The enter(), leave(), and visit_stmt() methods are meant to be called
>> from a DOM walk.   At any point throughout the walk, one can call
>> get_points_to() to get whatever an SSA is pointing to.
>> If this class is useful to others, we could place it in a more generic
>> location.
>> Tested on x86-64 Linux with a regular bootstrap/tests and by comparing
>> EVRP folds over ranger before and after this patch.
> Hmm, but why call it "points-to" - when I look at the implementation
> it's really about equivalences.  Thus,
>   if (var1_2 == var2_3)
> could be handled the same way.  Also "points-to" implies (to me)
> that &p[1] and &p[2] point to the same object but your points-to
> is clearly tracking equivalences only.
> So maybe at least rename it to pointer_equiv_analyzer?  ISTR

Good point.  Renaming done.  I've adjusted the changelog and commit 
message as well.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Implement-a-context-aware-pointer-equivalency-class-.patch
Type: text/x-patch
Size: 14852 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20210607/47ae38f8/attachment-0001.bin>

More information about the Gcc-patches mailing list