[LLVMdev] A tiny documentation patch to LLVM Language Reference Manual

[Rodney M. Bates]

OK, I now see how the i32 0 moves inside the struct.  But now I have more
questions.  According to "The Often Misunderstood GEP Instruction", the
type given to GEP as type of the starting pointer value need not be the
same as the type the value had when it was produced.  Yet you say it would
not typecheck as I miscorrected.  So, I am guessing the following:

1) In order to change the type in this way, I would need to insert an
    explicit bitcast.

2) Even though I can change the type, it still must be a pointer type
    (I see the language reference says this.)  So even with an explicit
    bitcast, my miscorrected example would still fail to typecheck for
    this latter reason.

3) The result of GEP is always a pointer type, the same as the starting
    type if only one index is given, different otherwise.

Am I understanding correctly?

On 04/22/2014 02:51 PM, Rafael Espíndola wrote:
> On 13 April 2014 11:19, Rodney M. Bates <rodney_bates at lcwb.coop> wrote:
>> Attached is a -u patch to llvm-3.4/docs/LangRef.rst.  The type I have
>> changed
>> in this one-index-at-a-time form of the example contradicts the type given
>> in
>> the preceding, fully inlined multiple index form.
>>
>> I believe this one is the incorrect one, because, as stated, it looks to me
>> like the following index operation would index the pointer again, advancing
>> by two more struct.STs, rather than selecting an element of the struct.ST
>> it already has.
>
> No, the documentation is correct. The fact that we are not indexing is
> represented by the first "i32 0" in the gep. Note that the IR would
> not typecheck with the change since it has the type of %t2 explicitly
> written down in:
>
>   %t3 = getelementptr %struct.RT* %t2, i32 0, i32 1
>
> Cheers,
> Rafael
>

-- 
Rodney Bates
rodney.m.bates at acm.org