On 6/7/21 12:29 PM, Aldy Hernandez via Gcc-patches wrote:
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.
Mostly just a question of the type choices in the implementation
of the ssa_equiv_stack class: m_stack is an auto_vec while
m_replacements is a plain array. I'd expect both to be the same
(auto_vec). Is there a reason for this choice?
If not, I'd suggest to use auto_vec. That way the ssa_equiv_stack
class shouldn't need a dtor (auto_vec doesn't need to be explicitly
released before it's destroyed), though it should delete its copy
and assignment.
Martin
Thanks.
Aldy
