[LLVMdev] proposed new rule for getelementptr

David Greene
Wed, 22 Jul 2009 19:33:12 -0000

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