[LLVMdev] proposed new rule for getelementptr

[Dan Gohman]

On Jul 22, 2009, at 12:56 PM, Eli Friedman wrote:


> On Wed, Jul 22, 2009 at 11:30 AM, Dan Gohman<gohman at apple.com> wrote:
>
>>  - The result value of an allocation instruction is associated with
>>
>>    the address range of the allocated storage.
>>
>
> Might want to clarify this to include calloc/realloc.

These sort of fall under the category of allocations done
outside of LLVM IR, but it'd be better to address this
case explicitly. I'll make a note of that.

>
>
>>  - A null pointer is associated with no addresses.
>>
>
> A null pointer in address space 0.

I'm not fond of weird address-space semantics, but for consistency
with what the optimizer is currently doing, you're right.

>
>
>>  - 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.
>>
>
> I assume you mean inttoptr?

Yes.

>
>
>> A non-overflowing option for getelementptr would be useful to allow
>>
>> SCEVExpander and other passes to convert code like this:
>>
>>   %a = mul %x, 4
>>
>>   %b = add %y, %a
>>
>>   %c = getelementptr [4 x i8]* @Object, 0, %b
>>
>>
>>
>> into this:
>>
>>   %c = getelementptr [4 x i8]* @Object, %x, %y
>>
>
> So a "defined-overflow" gep would act like wrapping integer arithmetic
> in the width of the pointer?  Then what exactly is the definition of
> an "undefined-overflow" gep?  Here's a first shot at a definition:
> "Considering a GEP as a series of calculations, one for each index, if
> the result that would be obtained by performing exact arithmetic
> (treating the index as a signed integer) is outside the bounds of the
> address range of the base pointer, the result is undefined."


Yes, something like this. I had been thinking of defining gep overflow
in terms of integer overflow, and then just saying that since LLVM IR
doesn't usually know what the address is, the only way to be safe is to
stay within the object, but your suggestion might be simpler.

Also, for completeness, the conversion of indices to pointer-sized
integers shouldn't change their value, the multiplication of the
indices by array element sizes shouldn't overflow, and computing an
address one-past-the-end is ok.

Dan