From: Andrew MacLeod <amacleod@redhat.com>
To: Aldy Hernandez <aldyh@redhat.com>,
Richard Biener <richard.guenther@gmail.com>
Cc: GCC patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Implement a context aware points-to analyzer for use in evrp.
Date: Tue, 8 Jun 2021 08:32:47 -0400 [thread overview]
Message-ID: <de9f5417-ff46-eb62-fd53-c635dc95f3e3@redhat.com> (raw)
In-Reply-To: <89a33071-0e49-b3d8-5a3f-a6cce6019f04@redhat.com>
On 6/8/21 2:26 AM, Aldy Hernandez wrote:
>
>
> On 6/7/21 9:20 PM, Andrew MacLeod wrote:
>> On 6/7/21 9:30 AM, Richard Biener via Gcc-patches 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
>>> propagating random (symbolic) equivalences has issues.
>>
>> Yeah, pointer_equiv is probably more accurate. This is purely for
>> cases where we know a pointer points to something that isn't an
>> ssa_name. Eventually this is likely to be subsumed into a
>> pointer_range object, but unlikely in this release.
>>
>> I don't think this is actually doing the propagation though... It
>> tracks that a_2 currently points to &foo.. and returns that to either
>> simplifier or folder thru value_of_expr(). Presumably it is up to
>> them to determine whether the tree expression passed back is safe to
>> propagate. Is there any attempt in EVRP to NOT set the range of
>> something to [&foo, &foo] under some conditions? This is what the
>> change amounts to. Ranger would just return a range of [1, +INF],
>> and value_of_expr would therefore return NULL. This allows value_of
>> to return &foo in these conditions. Aldy, did you see any other
>> checks in the vr-values code?
>
> The propagation is done in the subst & fold engine when either
> value_of_expr or value_on_edge return a value that can be propagated.
> Propagations are not done blindly, as all uses of the result of
> value_o* are guarded with may_propagate_copy().
>
> The simplifier (vr-values) is not involved, as it uses range_of_expr
> which only returns constant ranges.
>
> Aldy
>
patch is OK, btw..
Andrew
next prev parent reply other threads:[~2021-06-08 12:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-07 10:10 Aldy Hernandez
2021-06-07 10:12 ` Aldy Hernandez
2021-06-07 13:30 ` Richard Biener
2021-06-07 18:29 ` Aldy Hernandez
2021-06-09 17:10 ` Martin Sebor
2021-06-09 18:50 ` Aldy Hernandez
2021-06-09 19:01 ` Martin Sebor
2021-06-07 19:20 ` Andrew MacLeod
2021-06-08 6:26 ` Aldy Hernandez
2021-06-08 12:32 ` Andrew MacLeod [this message]
2021-06-08 7:26 ` Richard Biener
2021-06-08 14:31 ` Andrew MacLeod
2021-06-09 11:32 ` Richard Biener
2021-06-09 19:02 ` Andrew MacLeod
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=de9f5417-ff46-eb62-fd53-c635dc95f3e3@redhat.com \
--to=amacleod@redhat.com \
--cc=aldyh@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).