[LLVMdev] proposed new rule for getelementptr

[Török Edwin]

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?

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?

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

Best regards,
--Edwin