[LLVMdev] proposed new rule for getelementptr

Dan Gohman gohman at apple.com
Wed Jul 22 14:42:40 PDT 2009


On Jul 22, 2009, at 2:27 PM, Török Edwin wrote:


> On 2009-07-22 21:30, Dan Gohman wrote:
>
>> Hello,
>>
>>
>>
>> I'm working on refining the definition of getelementptr (GEP) to
>>
>> clarify its semantics and to allow front-ends to provide additional
>>
>> information to optimization passes.
>>
>>
>>
>> To help support this, I'd like to propose the following rule:
>>
>>
>>
>> Any memory access must be done though a pointer value associated
>>
>> with with address range of the memory access, otherwise the behavior
>>
>> is undefined.
>>
>>
>>
>> "associated with" is defined as follows:
>>
>>
>>
>>  - A pointer value formed from a getelementptr instruction is
>>
>>    associated with the addresses associated with the first operand of
>>
>>    the getelementptr.
>>
>>  - An addresses of a global variable is associated with the address
>>
>>    range of the variable's storage.
>>
>>  - The result value of an allocation instruction is associated with
>>
>>    the address range of the allocated storage.
>>
>>  - A null pointer is associated with no addresses.
>>
>>  - 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.
>>
>>  - 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 happens when you allocate more room for a variable than its type
> says it needs,
> and then access the variable beyond the limit of what its type would
> allow (but is otherwise valid, because you did allocate enough bytes)?
>
> I assume that the intention is to treat these as well defined accesses
> (pointer is within address range), is that right?
>
> I'm thinking of flexible array members in structs, and things like:
> struct foo
> {
>    ...
>    char var[1];
> };
>
> struct foo *x = malloc(sizeof(*x) + len);
> x->var[len-1];

Yep, this is fine. The types in a getelementptr are just used to
guide offset computation; they don't say anything about how the
underlying memory was allocated.

Dan





More information about the llvm-dev mailing list