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 Thu, Oct 11, 2012 at 9:41 PM, Uday P. Khedker <uday@cse.iitb.ac.in> wrote:
>
>
> Diego Novillo wrote, On Friday 12 October 2012 01:41 AM:
>
>> On Thu, Oct 11, 2012 at 11:53 AM, Uday P. Khedker <uday@cse.iitb.ac.in>
>> wrote:
>>>
>>>
>>>>
>>>> That's actually not true.  In fact existing GCC pointer analysis is
>>>> flow-sensitive for all SSA pointers.
>>>
>>>
>>>
>>> SSA provides partial flow sensitivity to the top level pointers. For
>>> deeper
>>> pointers, one needs to interleave SSA and points-to analysis. Besides, it
>>> cannot
>>> handle global pointers which are important at the interprocedural level.
>>
>>
>> Yes, for global pointers, but in GIMPLE we do not have 'deeper'
>> pointers.  Unless I'm misunderstanding you.  By 'deep pointers' you
>> mean 'foo->ptr1->ptr2'?  There are no memory expressions of that kind
>> in GIMPLE.
>
>
> I meant pointers that are pointed to by other pointers. However I see that
> GCC manages to solve common cases as a consequence of other optimizations so
> I will need some time to create an example that shows problems with deeper
> pointers but my main reason for not using SSA is that it seems fine for
> local analysis of scalars. When we introduce globals (the example that I
> gave in
> my previous mail http://gcc.gnu.org/ml/gcc/2012-10/msg00164.html) OR
> have function calls to which we pass pointers, SSA is helpless.
>
> 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.

Thanks,
Andrew Pinski

> However,
> the points-to sets dumped in file .052i.pta show that d can point to w.
>
>
> ANYTHING = { ANYTHING }
> READONLY = { READONLY }
> ESCAPED = { ESCAPED NONLOCAL a w x } same as main.clobber
> NONLOCAL = { ESCAPED NONLOCAL } same as f1
>
> STOREDANYTHING = { }
> INTEGER = { ANYTHING }
> main.clobber = { ESCAPED NONLOCAL a w x }
> main.use = { ESCAPED NONLOCAL a w x } same as main.clobber
> main.result = { ESCAPED NONLOCAL } same as D.1958_4
> main.varargs = { }
> a = { ESCAPED NONLOCAL w x } same as a.0_1
> w = { ESCAPED NONLOCAL }
> a.0_1 = { ESCAPED NONLOCAL w x }
> f1 = { ESCAPED NONLOCAL }
> x = { ESCAPED NONLOCAL }
> f2 = { ESCAPED NONLOCAL } same as f1
> d_3 = { ESCAPED NONLOCAL w x } same as a.0_1
> D.1958_4 = { ESCAPED NONLOCAL }
>
> The basic point I am trying to make is that SSA is primarily defined for
> locally scoped scalars and works excellently for them. In some cases
> it can be extended to handle other situations too. However, for
> pointers, starting from the first principles could be cleaner (and
> certainly more precise).
>
> Uday.


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