This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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.