[LLVMdev] proposed new rule for getelementptr

[Dan Gohman]

On Jul 22, 2009, at 12:33 PM, David Greene wrote:


> On Wednesday 22 July 2009 13:30, Dan Gohman wrote:
>
>
>>  - 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.
>>
>
> Do you mean inttoptr here?  And that "all pointer values that  
> contribute
> (directly or indirectly) to the computation of the pointer's value"  
> could
> equally mean "all pointer values that contribute (directly or  
> indirectly) to
> the computation of the integer's value?"

Yes, I meant inttoptr instead of ptrtoint here.

>
>
>>  - An integer value other than zero may be associated with address
>>
>>    ranges allocated through mechanisms other than those provided by
>>
>>    LLVM; such ranges shall not overlap with any ranges of address
>>
>>    allocated by mechanisms provided by LLVM.
>>
>
> What's the intent here?  Are you basically saying that memory  
> regions accessed
> through random integer arithmetic can't overlap memory regions  
> allocated by
> alloca, malloc, etc.?  If so, my sense is that's too demanding.  In  
> general
> one does not know the aliasing properties of addresses computed  
> entirely by
> integer arithmetic.  It could be some misguided user trying to  
> "help" the
> compiler by explicitly linearizing addressing or it could be an  
> embedded
> developer computing a memory-mapped I/O address.  There's just no  
> way to
> know.

The intent is to cover code like this:

     %p = alloca i32
     %q = inttoptr i64 0123456789 to i32*

Here, %p and %q are assumed to be non-aliasing. This kind of thing
is used by some JITs; they allocate objects via custom mechanisms
and then tell LLVM IR about the address of the objects via magic
integer constants like this. The optimizer is already making this
assumption today, though implicitly.

If the user hand-linearizes addressing using casts to integers,
it will still be supported -- that's what the broad language for
inttoptr above is intended to cover.

>
>
>> Front-ends that do crazy things to pointers may need to use
>>
>> ptrtoint+arithmetic+inttoptr instead of getelementptr. If the
>>
>> target-independent properties of getelementptr are needed, the
>>
>> "getelementptr null" trick may be useful.
>>
>
> To clarify, the ptrtoint+arithmetic+inttoptr would still be legal?

Yes, subject to constraints in the bullet point quoted at the
top of this email, which effectively just spelling out rules that
are already assumed today.

Dan