This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Track pure function call uses separately


> Ok, I have it "working" with something like the following.
>
> Basically we need to treat 'reachability vars' specially, for
> ESCAPED this is constraints of the form

FWIW, this problem only occurs if you try to compute escaping at the
same time as points-to.
I understand it is probably not worth computing escaping separately
(since it would more or less just double the time we are taking), i'm
just saying.
> initially add all fields of x to ESCAPED.  Probably better done by
> collapsing x - the solution of x will get all of ESCAPED through
> the *ESCAPED = ESCAPED constraint anyway, so no point in processing
> the fields of x separately.  (Ideally we would collapse during
> solving, but that doesn't look easily doable(?))

You can unify and collapse any variables you like during either
solving or prior to solving.
Just unify the fields to the base.

Unifying more variables will never cause the points-to sets to be
wrong, only less precise.
:)

In fact, if you were to unify every RHS and LHS where you see "LHS =
RHS", you would end up with the same results as steensgaard's
analysis.

>
>  ESCAPED = *ESCAPED
>
> I hacked do_sd_constraint to handle this special case - we need
> to add all fields the solution in ESCAPED can reach.
>
> So, it gets somewhat ugly, and of course I am not sure that
> variable unification will not get in our way ... (when exactly
> are two variables unified?)

Two variables are unified prior to solving when we can prove they will
end up with the same points-to set based on the constraints.
This is a subset of "when they will have the same points-to set".
In theory, you should expect any variables that, based only on the
constraints, will end up with the same points-to set, to be unified.
They may not be (due to difficulties in proving it), but it is not
"wrong" for it to happen.

This is the limit of what we do, because anything more could affect
precision of analysis.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]