[LLVMdev] proposed new rule for getelementptr

[Eli Friedman]

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.

>  - A null pointer is associated with no addresses.

A null pointer in address space 0.

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

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

-Eli