[LLVMdev] proposed new rule for getelementptr

[Eli Friedman]

On Mon, Jul 27, 2009 at 9:21 PM, Vikram S. Adve<vadve at illinois.edu> wrote:
>>  - An addresses of a global variable is associated with the address
>>    range of the variable's storage.
>>  - The result value of an allocation instruction is associated with
>>    the address range of the allocated storage.
>>  - A null pointer is associated with no addresses.
>
> Null in C is always implemented as 0, and address 0 is a perfectly
> valid address in kernel code.  What happens there?

It doesn't work; this documentation change is just clarifying that.
There are various ugly ways to deal with this at the moment, like
inline asm, but I'm not sure what the right thing to do here is...

>>  - A pointer value formed by a ptrtoint is associated with all address
>>    ranges of all pointer values that contribute (directly or
>>    indirectly) to the computation of the pointer's value.
>
> This seems technically well defined (after rephrasing in terms of
> inttoptr, as you said), but can be very expensive for a pointer
> analysis to track.  I'm not sure any of our current analyses actually
> track this in any sense, except DSA which only does this as an option
> that hasn't been used for a while and has likely bit-rotted.  This
> means the "ptrtoint+arithmetic+inttoptr" case, though legal, should
> lead to very poor aliasing results.  I guess you could argue that
> current LLVM passes don't do any better?

On one end, this is only slightly more general than what BasicAA
already assumes, which is roughly "if a pointer doesn't escape, it
doesn't alias any other pointer." And on the other end, we don't want
to break legal C code like
http://llvm.org/bugs/show_bug.cgi?id=2831#c11 .  I don't think there's
really much choice involved in this definition.

-Eli