[LLVMdev] proposed new rule for getelementptr

[Dan Gohman]

On Jul 22, 2009, at 1:13 PM, David Greene wrote:


> On Wednesday 22 July 2009 15:05, Dan Gohman wrote:
>
>
>> 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.
>>
>
> But how do you know 0123456789 doesn't point to the same thing %p  
> does?
> I understand it's highly unlikely and that we'd like to define that
> there's no aliasing.  I just get a little squeemish, especially when
> considering embedded devices.

Without this assumption, much of LLVM would be useless. It's
more practical to make LLVM entirely useless to obscure
hypothetical users than to make it mostly useless to most
current real users.

> Those rules are ok, I think.  It's the computed-integer problem that
> is gnawing at me.
>
> I *think* the C standard says there can't be an alias and I assume the
> Fortran standard does as well.  But even so, we all know that users
> often ignore standards when convenient.

If anyone comes forward with a real problem that this is causing,
we'll consider the problem in context, where there may be alternative
solutions.

Dan