[PATCH] Fix points-to / call-clobber solution in the face of pointer-arithmetic

[Richard Guenther]

On Fri, 4 Jul 2008, Richard Guenther wrote:

> On Fri, 4 Jul 2008, Richard Guenther wrote:
>
>> On Fri, 4 Jul 2008, Daniel Berlin wrote:
>> 
>>> On Fri, Jul 4, 2008 at 10:14 AM, Richard Guenther <rguenther@suse.de> 
>>> wrote:
>>>> 
>>>> This (again) fixes how we handle pointer-arithmetic in (field-sensitive)
>>>> PTA.
>>>> 
>>>> First, as shown in the single testcase included, we have to be able
>>>> to compute the reachability set of a pointer that points after
>>>> an object - which we cannot do right now because the points-to set
>>>> we create at the moment is empty in that case.
>>>> 
>>>> Second, repeated increments smaller than a sub-field size do not
>>>> cause the solution to change, so the solution for p + 2 + 2 may
>>>> be different of that for p + 4.  This problem is a real problem
>>>> if we have a sub-field which includes multiple "real" fields
>>>> (which happens for structs with variable sized fields, or of course
>>>> with the patch globbing non-pointer fields).
>>>> 
>>>> The solution to the above problems is for 1) use the last sub-field
>>>> as the solution for off-variable pointers
>>> 
>>> 
>>> Err, no.
>>> This will do Bad Things (TM) for indirect function calls, where the
>>> last sub field is equivalent to the last argument ;)
>>> Unless you are going to mark which varinfos are indirect function
>>> calls, and not do this for them.
>> 
>> Uh, so when are we doing pointer arithmetic on a function decls
>> varinfo?  Also I don't see that we for a function pointer
>> generate something special (so why are indirect functions broken?).
>> I would also be surprised if a function argument would appear
>> in a points-to set at any time ;)
>> 
>> But maybe you can clarify?  (or even produce a testcase I can look
>> at?  Yes, I realize this only happens with ipa-pta)
>
> Ok, probably as easy as
>
> int foo (int i, int j)
> {
>  int *p = &i;
>  j = 0;
>  p += 1;
>  return *p;
> }
>
> but you realize that the parameter varinfos have wrong size anyway, so
>
> struct F { int i; int j; };
>
> int foo (struct F f, int j);
> {
>  int *p = &f.i;
>  p++;
> }
>
> p will point to some weird place (parameters have a size of 1 bit!?).
>
> This representing parameters as sub-fields of a variable that is
> the function decl looks fragile.
>
> IMHO my patch doesn't make it more broken than it already is ;)

wrong-code with the following testcase (if the ipa-pta result
would be used):

void bar (void *x)
{
   char *p = (char *)x - 1;
   *p = 0;
}
char foo (char f, char p1, char p2, char p3, char p4, char p5,
           char p6, char j)
{
   char *p = &f;
   f = 1;
   p++;
   bar (p);
   return f;
}

the argument to bar is PTAed to be j, so we could optimize
the return f to return 1.

Richard.