This is the mail archive of the gcc@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: Fully flow and context sensitive points-to analysis in GCC 4.6.0


On Fri, Oct 12, 2012 at 7:41 AM, Uday P. Khedker <uday@cse.iitb.ac.in> wrote:
>
>
> Andrew Pinski wrote, On Friday 12 October 2012 10:29 AM:
>
>
>>> Here's an example:
>>>
>>> main()
>>> {
>>>          int **p;
>>>          int *a, *d;
>>>          int w, x;
>>>
>>>          a = &w;
>>>          f1(a);
>>>          p = &a;
>>>          a = &x;
>>>          f2(p);
>>>          d = a;
>>>
>>>          return *d;
>>> }
>>>
>>> It is clear that d can only point to x and can never point to w.
>>
>>
>> I think you are wrong there.
>>
>> int *a1;
>> void f1(int *a)
>> {
>>    a1 = a;
>> }
>>
>> void f2(int **p)
>> {
>>    *p = a1;
>> }
>>
>> That will change a to &w after f2 is called.  So it looks like your
>> aliasing analysis does not take into account escaping like it should.
>> This is the whole point of marking a as escaped.  Maybe I missed
>> something here though but d can point w with my functions for f1 and
>> f2.
>
>
> Ah, you caught me there, but I think I can escape, at least in this
> situation :-)
>
> The call to f1 is not central to the point I am making; I had included it
> only to ensure
> that the assignment a=&w doesn't get eliminated by dead code elimination.
> Since you
> decided to hold the address of a into a1 through function f1, let me
> eliminate the
> call to f1 and make the assignment a=&w live in some other way. Here's the
> changed code:
>
>
> main()
> {
>         int **p;
>         int *a, *d;
>         int w, x;
>
>         d = &x;
>         a = &w;
>         if (f1())
>
>         {
>                 p = &a;
>                 a = &x;
>                 f2(p);
>                 d = a;
>         }
>
>         return *d + *a;
> }
>
> Now when f2 is called, a definitely does not point to w. Hence d should not
> point to w.
> And yet, the dump shows that d continue to point to w.
>
> In any case, your point about escaping variables strengthens my point about
> inappropriateness
> of SSA for pointer analysis, although not through this example.

The point is we are only ever interested at what SSA names point to
when we use points-to information.  Even the current IPA-PTA code
uses internal representation for representing globals and aggregates
(but yes, not flow-sensitively).  For

int *a;

foo ()
{
   a = ...;
...

   use (a);
}

we _always_ see

  ssa_name_1 = a;
  use (ssa_name_1);

so you have a place to associate your flow-sensitive and context-sensitive
points-to-info with (the SSA name).  My point is that for _using_ the
points-to info flow-sensitivity provided by SSA form is enough.  For computing
it you of course need to flow-sensitively process assignments to 'a'.

Richard.

> Uday.
>
>


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