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

[Dan Gohman]

On Feb 18, 2010, at 1:59 AM, Duncan Sands wrote:

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

You're right. I've cleaned up the wording here to make this explicit.

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

That's true. However, you can do this if you measure the distance dynamically,
instead of just assuming 4. With GEP it's not permitted in either case.

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

Fixed.

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

The inbounds keyword applies to the pointer computation itself.

inbounds is to GEP as nsw is to add.

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

Yep; LLVM has effectively had this rule for a long time. There have been a few
bug reports on it; the resolution was that the user code was buggy.

It is valid to do this kind of arithmetic if you use
ptrtoint+arithmetic+inttoptr instead of GEP though. I've added some
text to mention this.

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

Thanks. See my comments there.

Thanks for the review!

Dan