llvm dev - Jun 2010 - [LLVMdev] For clarifying the "<Result>" in Instructions

Hello Reid, 

Thanks. 
> Yes, it's an integral part of the Instruction.  You can change it by
> providing a name when you create the instruction.
Following your hint, can I understand in this following way?
 
The name (denoted by "<result>") is actually a referrer to the
instruction .
Consider this instruction: 
  %this_addr = alloca %struct.String*             ; <%struct.String**>
[#uses=4]
Here "%this_addr" (which is not a argument) is actually a string. 
Am I right? 

And this name is recorded in the symbol table of a module.  In case that an
instruction does not have a name, what then happens? I mean, will the
symbol table contains an entry for it?

Thanks, 

Best, 
Xiaolong
 
> On Thu, Jun 10, 2010 at 8:34 AM, Xiaolong Tang <xiaolong.snake at
gmail.com> wrote:
> >
> > In the language specifications, many instructions have this form:
> >
> >  <result> = ...
> >
> > So, where is "<result>" defined? Is it an integral
part of an instruction?
> > Consider the "getelementptr" instruction:
> >
> >  <result> = getelementptr <pty>* <ptrval>{,
<ty> <idx>}*
> >
> > How is the "<result>" represented?

On Thu, Jun 10, 2010 at 9:00 AM, Xiaolong Tang <xiaolong.snake at
gmail.com> wrote:
>
> Hello Reid,
>
> Thanks.
>
>> Yes, it's an integral part of the Instruction.  You can change it
by
>> providing a name when you create the instruction.
>
> Following your hint, can I understand in this following way?
>
> The name (denoted by "<result>") is actually a referrer to
the instruction .
> Consider this instruction:
>  %this_addr = alloca %struct.String*             ; <%struct.String**>
[#uses=4]
> Here "%this_addr" (which is not a argument) is actually a string.
> Am I right?
More or less.  %this_addr is a pointer to a stack slot which contains
a pointer to something of type struct.String.  The typical pattern for
frontends modelling local variables is to create an alloca for every
local, and store and load from it on assignment.
> And this name is recorded in the symbol table of a module.  In case that an
> instruction does not have a name, what then happens? I mean, will the
> symbol table contains an entry for it?
The name is local to the function in which it's defined, not the
module.  If you don't give it a name, instructions are given numeric
names starting from 0, ie %0, %1, %2...

Reid

On Fri, Jun 11, 2010 at 4:33 AM, Reid Kleckner <rnk at mit.edu>
wrote:
> On Thu, Jun 10, 2010 at 9:00 AM, Xiaolong Tang <xiaolong.snake at
gmail.com> wrote:
>>
>> Hello Reid,
>>
>> Thanks.
>>
>>> Yes, it's an integral part of the Instruction.  You can change
it by
>>> providing a name when you create the instruction.
>>
>> Following your hint, can I understand in this following way?
>>
>> The name (denoted by "<result>") is actually a referrer
to the instruction .
>> Consider this instruction:
>>  %this_addr = alloca %struct.String*             ;
<%struct.String**> [#uses=4]
>> Here "%this_addr" (which is not a argument) is actually a
string.
>> Am I right?
>
> More or less.  %this_addr is a pointer to a stack slot which contains
> a pointer to something of type struct.String.  The typical pattern for
> frontends modelling local variables is to create an alloca for every
> local, and store and load from it on assignment.
>
>> And this name is recorded in the symbol table of a module.  In case
that an
>> instruction does not have a name, what then happens? I mean, will the
>> symbol table contains an entry for it?
>
> The name is local to the function in which it's defined, not the
> module.  If you don't give it a name, instructions are given numeric
> names starting from 0, ie %0, %1, %2...
The names are optional and only really used for the .ll human readable
assembly form of the IR, the name is the name of the instruction which
is the same as the name of its value.  when building IR
programatically using the API you use Value*'s to refer to the
instructions.
>
> Reid