[llvm-commits] [llvm] r96526 - in /llvm/trunk/docs: AdvancedGetElementPtr.html index.html

[Duncan Sands]

Hi Dan,

> +  <p>Also, GEP carries additional pointer aliasing rules. It's invalid to take a
> +     GEP from one object and address into a different separately allocated
> +     object. IR producers (front-ends) must follow this rule, and consumers
> +     (optimizers, specifically alias analysis) benefit from being able to rely
> +     on it.</p>

are you sure?  I thought it was fine to have a GEP point outside an object (and
possibly into another one) as long as you don't try to load from or store to
that object.  Also, the "no assumptions about where allocated objects are
allocated" rule applies not just to GEP as far as I know.  For example, suppose
you have two consecutive "alloca i32", then do a ptrtoint on the first, add 4
bytes, and do an inttoptr.  You cannot assume that the result points into the
second alloca, yet there are no GEP's here.

> +  <p>However, for of the underlying integer computation implied, there
> +     is no difference.</p>

for of -> for

> +  <p>The second sense of being out of bounds is computing an address that's
> +     beyond of the actual underlying allocated object.</p>

beyond of -> beyond

> +  <p>With the <tt>inbounds</tt> keyword, the result value of the GEP is
> +     undefined if the address is outside the actual underlying allocated
> +     object and not the address one-past-the-end.</p>

Are you sure, I thought only dereferencing such a pointer was the problem...

> +  <a name="lead0"><b>Can I cast an object's address to integer and add it
> +                     to null?</b></a>
> +</div>
> +<div class="doc_text">
> +  <p>You can compute an address that way, but you can't use that pointer to
> +     actually access the object if you do, unless the object is managed
> +     outside of LLVM.</p>
> +
> +  <p>The underlying integer computation is sufficiently defined; null has a
> +     defined value -- zero -- and you can add whatever value you want to it.</p>
> +
> +  <p>However, it's invalid to access (load from or store to) an LLVM-aware
> +     object with such a pointer. This includes GlobalVariables, Allocas, and
> +     objects pointed to by noalias pointers.</p>

Woah, that's an exciting rule!  Has this always been the case?

> +  <p>Instead, you should cast your pointer types and use arrays instead of
> +     vectors for addressing. Arrays have the same in-memory representation
> +     as vectors, so the addressing is interchangeable.</p>

Hah!  See PR1784.

Ciao,

Duncan.