Re: [PATCH][alias-improvements] Handle unknown offsets in PTA

[Daniel Berlin <dberlin at dberlin dot org>]

On Sun, Feb 1, 2009 at 4:08 PM, Richard Guenther <rguenther@suse.de> wrote:
> On Sun, 1 Feb 2009, Daniel Berlin wrote:
>
>> On Sat, Jan 31, 2009 at 2:06 PM, Richard Guenther <rguenther@suse.de> wrote:
>> >
>> > This implements handling of unknown offset constraints in the PTA
>> > solver (by using a special offset value).  Now the only thing where
>> > we (needlessly) fall back to anything is negative constant offsets
>> > (to be addressed with a followup patch).
>> >  Pointer offsets
>> > only need special handling with field-sensitive analysis.  There
>> > if your points-to set S includes x.N then the constraint
>> > y = S + off needs to add all fields of x to the solution of y.
>> >
>> This is fine, but it may actually be better to make it a separate
>> constraint type.
>> The way you have it now will mean less offline optimization.
>>
>> For example, given two other pointer equivalent variables who have a
>> constraint with unknown offset, with the below we will not merge them,
>> when in fact, we could since they will still end up with the same
>> points-to set.
>>
>> (This could also be taken care of by special casing UNKNOWN_OFFSET in
>> offline optimizations)
>
> Hmhm, I have it now "optimized" (well, the original patch had some
> errors) and extended to handle negative constant offsets.  Patch
> appended below, a version that missed some cleanups bootstrapped & tested
> ok, this one is in the testing stage.
>
> I don't understand what you mean with the missing merging?  Do you mean
>
>  p = &a + UNKNOWN
>  q = &a + UNKNOWN
>
> so p and q are not merged?  How is this different for the case if the
> offset is constant (is it?)?

When the offset is constant, the points-to set is not necessarily equal.
It depends on what caused the constraint (IE whether it actually
occurs in the source or not).
You certainly can merge most cases causing constant offsets, and we don't.