[LLVMdev] proposed new rule for getelementptr

[Dan Gohman]

On Jul 22, 2009, at 1:28 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.
>>
>>
>>
>
> If I compute an out-of-bounds GEPs and use it in ICMP is that  
> undefined
> behaviour, or wrapping behaviour?

This will be addressed when the wrapping option for GEP is available.
A wrapping GEP will provide wrapping behavior, and a non-wrapping
GEP will have an undefined result on overflow. So it's up to the
front-end to decide which one it wants.

>
> Instcombine currently does this transform ((gep Ptr, OFFSET) cmp Ptr)
> ---> (OFFSET cmp 0), which is perfectly
> fine when GEP is assumed to have undefined behavior on overflow, but  
> is
> wrong if GEP is allowed to overflow
> with well defined behavior (it wraps).
>
> Also will can the behavior of GEP be changed depending on llvm-gcc's
> -fno-strict-aliasing/-fwrapv/-fno-strict-pointer-overflow flags?

Yes. To implement -fwrapv, the front-end can omit any of the no-overflow
flags, and choose the wrapping form of GEP, as appropriate.

I'm not familiar with -fno-strict-pointer-overflow. Do you mean
-fno-strict-overflow? I guess for LLVM that would be equivalent
to -fwrapv.

-fno-strict-aliasing is not impacted.

>
>
>> 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.
>>
>
> Will various optimizations make sure they don't introduce undefined
> operations in programs with otherwise well defined semantics?
> I think instcombine may turn them into GEPs, thus transforming a  
> program
> with well defined semantics according to above rules into
> undefined semantics. Of course if the optimizer can see that the  
> access
> is always well defined it should do this transform.

Yes. One of the goals of this effort is to legitimize some of what the
optimizer is already doing, and another is to make some of the things
it's doing dependent on explicit permission in the form of no-overflow
flags.

Dan