Re: [PATCH][RFC] Make restrict work properly on the tree level

[Richard Guenther <rguenther at suse dot de>]

On Mon, 5 May 2008, Daniel Berlin wrote:

> On Mon, May 5, 2008 at 1:53 PM, Daniel Berlin <dberlin@dberlin.org> wrote:
> > On Mon, May 5, 2008 at 10:29 AM, Richard Guenther <rguenther@suse.de> wrote:
> >  >
> >  >  This is a first (quick) shot to make restrict work properly with
> >  >  tree level aliasing.  Now that we got oracle queries in place we can
> >  >  do the right thing with the "two pointers based on different restrict
> >  >  pointers" thing by simply using PTA and propagating "bases" at the
> >  >  time we propagate DECL_NO_TBAA_P information.
> >  >
> >  >  The setup for parameters is the easiest, but other cases could be
> >  >  handled the same.  One problem I faced is that the points-to solver
> >  >  quickly collapses pointers if they have the same points-to sets - which
> >  >  obviously makes the "based on" analysis fail.  Thus the "hack" in
> >  >  label_visit to avoid this.
> >
> >  Don't do this in label visit, it was built to work without any
> >  knowledge of variable infos, only working on the graph.
> 
> 
> Also, preventing label_visit from doing it's job this way will cause
> it to miss other non-related equivalences.
> Again, better to take the results and just skip unification of
> variables with unrelated restrict_base_id.

I tried that, but neither adjusting unite () or unify_nodes () to do that
has the desired effect.  With both I get

Equivalence classes for Direct node id 4:p_1 are pointer: 5, location:0
Equivalence classes for Direct node id 5:q_3 are pointer: 5, location:0
Equivalence classes for Indirect node id 6:v_2 are pointer: 6, location:0
Equivalence classes for Indirect node id 7:w_4 are pointer: 7, location:0
Rewriting constraints and unifying variables
Cannot unite q_3 to p_1 based on different restrict qualified pointers
Cannot unite q_3 to p_1 based on different restrict qualified pointers
Uniting pointer but not location equivalent variables
Finding indirect cycles
Solving graph
v_2 is based on restrict p_1(D)
w_4 is based on restrict p_1(D)
Points-to sets

NULL = { }
ANYTHING = { ANYTHING }
READONLY = { ANYTHING }
INTEGER = { ANYTHING }
p_1 = { ANYTHING }
q_3 = { }
v_2 = { ANYTHING }
w_4 = { ANYTHING }


so it looks like that q_3 is not processed.  With the labeling change
I had ensured that both p_1 and q_3 get different pointer_labels
(not the same pointer: 5).

find_equivalent_node still finds p_1 if asked for q_3...  (obviously,
as they have the same label) and the constraints are rewritten to use
p_1 only.

It looks like a representative for a label where any of the pointers
is based on different restrict pointers shall not be set?

Another option would be to run the restrict propagation before
variable substituting and constraint rewriting solely based on the
constraints (though that would leave us with the cycles).  At that
time we can as well not use PTA but implement this stuff as a
separate propagation pass...

Note that giving the restrict marked pointers different labels looked
correct to me - after all only the sources we know to be different
are marked at this point (as they are parameters they are all pointing
to anything and thus unified otherwise).

Ideas? ;)

Thanks,
Richard.