[LLVMdev] proposed new rule for getelementptr

[Eli Friedman]

On Wed, Jul 22, 2009 at 12:33 PM, David Greene<dag at cray.com> wrote:
>>   - 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.?

Yes, I think that's the intent.

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

If a memory-mapped I/O address aliases the stack, there's something
seriously messed up going on... of course, we wouldn't assume anything
about whether 1000 and 2000 alias.

>> 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, I think that is the intent.

-Eli