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

[Daniel Berlin]

On Fri, Jul 4, 2008 at 2:45 PM, Richard Guenther <rguenther@suse.de> 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!?).

The size should be 1 on them.  We don't try to treat them field sensitively.


>
> This representing parameters as sub-fields of a variable that is
> the function decl looks fragile.

Actually, it's the standard way to do it nowadays, and about 1000x
easier than any of the alternatives (all of which involve special
casing calls, and then further special casing indirect calls).

Given that a set of function parameters is, in a sense, a structure
that we are passing to a function, i don't see how it's fragile in any
case.

>
> IMHO my patch doesn't make it more broken than it already is ;)
>
> Richard.
>