[LLVMdev] proposed new rule for getelementptr

[David Greene]

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?"

>   - 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.

> 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?

                           -Dave