Rodney M. Bates
2014-Apr-24 00:41 UTC
[LLVMdev] A tiny documentation patch to LLVM Language Reference Manual
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