[LLVMdev] Question about local variables
Nick Lewycky
nlewycky at google.com
Mon Oct 24 16:16:01 PDT 2011
On 24 October 2011 15:50, Ryan Taylor <ryta1203 at gmail.com> wrote:
> Nick,
>
> Oh, sorry. So there are lots of "void" operations, I basically just want
> to print out the operation name, it's dest operands and source operands,
What's a dest operand? The term "operand" in LLVM always refers to the
inputs (ie., an add has two operands).
> that's it, I was just hoping for a cleaner interface to this information.
> It doesn't sound like there is one.
>
> Overall, I'm just trying to extract, the operation name, the source
> operands, the dest operands along with dst and src widths/signs, etc.
Looking at "%x = add i32 %y, 1" the pieces here are:
"%x" the name of the instruction (I->getName())
"add" the instruction opcode (I->getOpcodeName())
"i32" the first operand type (I->getOperand(0)->getType())
"%y" the first operand (I->getOperand(0)->getName())
"1" the second operand (type is implicit here because a binop needs the
same type on both sides). (I->getOperand(1))
LLVM integer types are signless, so I can't help you there.
Nick
On Mon, Oct 24, 2011 at 3:43 PM, Nick Lewycky <nlewycky at google.com> wrote:
>
>> [please remember to cc llvmdev]
>>
>> On 24 October 2011 13:20, Ryan Taylor <ryta1203 at gmail.com> wrote:
>>
>>> Nick,
>>>
>>> Thanks, this is not really viable as I'd have to check every single
>>> instruction like this, seems like there is a lot of overhead associated with
>>> this solution.
>>>
>>
>> I don't know what problem you're solving?
>>
>> Nick
>>
>> On Mon, Oct 24, 2011 at 11:48 AM, Nick Lewycky <nlewycky at google.com>wrote:
>>>
>>>> On 24 October 2011 10:31, Ryan Taylor <ryta1203 at gmail.com> wrote:
>>>>
>>>>> Nick,
>>>>>
>>>>> Is there a clean way to tell the difference between dst and src
>>>>> operands in operations without assignment "=" (ie, store)?
>>>>>
>>>>
>>>> StoreInst has getValueOperand() and getPointerOperand(). See
>>>> http://llvm.org/doxygen/de/d9c/classllvm_1_1StoreInst.html .
>>>>
>>>> We don't print out a name for instructions that are void typed, since
>>>> there's no sense trying to refer to them again. You can test for that with
>>>> Inst->getType()->isVoidTy().
>>>>
>>>> Nick
>>>>
>>>> On Mon, Oct 24, 2011 at 9:52 AM, Ryan Taylor <ryta1203 at gmail.com>wrote:
>>>>>
>>>>>> Nick,
>>>>>>
>>>>>> I forgot to thank you, thanks!
>>>>>>
>>>>>>
>>>>>> On Sat, Oct 22, 2011 at 2:25 PM, Nick Lewycky <nicholas at mxc.ca>wrote:
>>>>>>
>>>>>>> Ryan Taylor wrote:
>>>>>>>
>>>>>>>> Nick,
>>>>>>>>
>>>>>>>> Ah, forgot the -o, thanks, silly mistake.
>>>>>>>>
>>>>>>>> So how would you extract "add" from the instruction "%A"?
>>>>>>>>
>>>>>>>
>>>>>>> I->getOpcodeName().
>>>>>>>
>>>>>>>
>>>>>>> Yes, this is sort of what I am trying to do. The instnamer works
>>>>>>>> fine
>>>>>>>> for the local variables and I already had the constants sorted out.
>>>>>>>>
>>>>>>>
>>>>>>> Great!
>>>>>>>
>>>>>>> Nick
>>>>>>>
>>>>>>>
>>>>>>>> On Sat, Oct 22, 2011 at 1:21 PM, Nick Lewycky <nicholas at mxc.ca
>>>>>>>> <mailto:nicholas at mxc.ca>> wrote:
>>>>>>>>
>>>>>>>> Ryan Taylor wrote:
>>>>>>>>
>>>>>>>> Nick,
>>>>>>>>
>>>>>>>> Also, I forgot to mention I had no luck with instnamer, it
>>>>>>>> still left
>>>>>>>> the local variables as "%slotNum", it didn't name them,
>>>>>>>> unless I
>>>>>>>> used
>>>>>>>> -instnamer wrong:
>>>>>>>>
>>>>>>>> opt -instnamer <file.bc> file2.bc
>>>>>>>>
>>>>>>>>
>>>>>>>> Almost, use -o to specify output: opt -instnamer file.bc -o
>>>>>>>> file2.bc
>>>>>>>>
>>>>>>>>
>>>>>>>> Those are the ones I am refering to. The description for
>>>>>>>> instnamer says that it names unnamed instructions (not
>>>>>>>> operands), or am I confused on the terminology here?
>>>>>>>>
>>>>>>>>
>>>>>>>> Ah, I see. The operand of an instruction is some other Value, but
>>>>>>>> it's not a subclass of Value like Instruction is. Allow me to
>>>>>>>> elaborate.
>>>>>>>>
>>>>>>>> Here's some example IR:
>>>>>>>>
>>>>>>>> declare i32 @test(i32 %arg) {
>>>>>>>> %A = add i32 %arg, 1
>>>>>>>> %B = mul i32 %A, 2
>>>>>>>> ret i32 %B
>>>>>>>> }
>>>>>>>>
>>>>>>>> The llvm::Value hierarchy contains Instruction, Argument and
>>>>>>>> Constant (among others). The operands of %A are "i32 %arg" and
>>>>>>>> "i32
>>>>>>>> 1" where %arg is an Argument and 1 is a Constant.
>>>>>>>>
>>>>>>>> So, saying that "but it doesn't name operands" is moot, because
>>>>>>>> it
>>>>>>>> goes through and names all the arguments and instructions, which
>>>>>>>> means that it's going to name all the operands -- except for
>>>>>>>> constants.
>>>>>>>>
>>>>>>>> Firstly, constants (like "i32 1") aren't allowed to have names.
>>>>>>>> Secondly, some Constants (GlobalValues which includes functions
>>>>>>>> and
>>>>>>>> global variables) are allowed to have names, but the instnamer
>>>>>>>> won't
>>>>>>>> touch them.
>>>>>>>>
>>>>>>>>
>>>>>>>> For example, if I print out I->getName I get "add" not "x" or
>>>>>>>> "y", but when I do Value *V = I->getOperands(loop) and then
>>>>>>>> do
>>>>>>>> V->getName, then it prints out the name of the operand. Am I
>>>>>>>> going about this backwards? It sounds like it from the
>>>>>>>> terminology you are using (calling an operand an
>>>>>>>> instruction).
>>>>>>>>
>>>>>>>>
>>>>>>>> If you have the Instruction* for "%A", then getName() will return
>>>>>>>> "A", not "add". It may be the case that you have "%add = add i32
>>>>>>>> %arg, 1" in which case it would return "add". :)
>>>>>>>>
>>>>>>>> If you call %A->getOperand(0) then you'll get the Value* whose
>>>>>>>> getName() returns "arg", and also you can cast pointer to
>>>>>>>> Argument*.
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't mean to be contentious (as I really appreciate your
>>>>>>>> time
>>>>>>>> and help) but apparently someone does use it, me. When going
>>>>>>>> from source to source it's needed to keep track of the
>>>>>>>> variables. Or am I missing something here too?
>>>>>>>>
>>>>>>>>
>>>>>>>> Sure, no problem! I'm happy to explain how LLVM works.
>>>>>>>>
>>>>>>>> I'm not sure what you mean when you say you're going
>>>>>>>> source-to-source through LLVM. Are you taking a language (say
>>>>>>>> C++)
>>>>>>>> compiling it to LLVM IR, then trying to produce another language
>>>>>>>> back out (say Javascript)? I would give up on trying to map the
>>>>>>>> output variable names back to the input ones. Think of LLVM IR
>>>>>>>> like
>>>>>>>> you would x86 assembly, that information is long gone.
>>>>>>>>
>>>>>>>> If you mean that you're doing LLVM IR -> LLVM IR, then instead of
>>>>>>>> names use the Value pointers directly. Like names, they refer to
>>>>>>>> the
>>>>>>>> values.
>>>>>>>>
>>>>>>>> Nick
>>>>>>>>
>>>>>>>>
>>>>>>>> ?
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Oct 22, 2011 at 12:51 PM, Nick Lewycky <
>>>>>>>> nicholas at mxc.ca
>>>>>>>> <mailto:nicholas at mxc.ca>
>>>>>>>> <mailto:nicholas at mxc.ca <mailto:nicholas at mxc.ca>>> wrote:
>>>>>>>>
>>>>>>>> Ryan Taylor wrote:
>>>>>>>>
>>>>>>>> Nick,
>>>>>>>>
>>>>>>>> Unfortunately this doesn't answer my question I
>>>>>>>> don't think. It
>>>>>>>> seems that -instnamer, as you mention, names the
>>>>>>>> instructions
>>>>>>>> but still
>>>>>>>> does not name the local variables.
>>>>>>>>
>>>>>>>>
>>>>>>>> What other local variables are you referring to? When
>>>>>>>> AsmWriter
>>>>>>>> prints "%y = add i32 %x, 1", the name of that add
>>>>>>>> instruction is "y"
>>>>>>>> and "x" is the name of another instruction or argument.
>>>>>>>> If
>>>>>>>> it has no
>>>>>>>> name, the AsmWriter emits a number ("%0"), by counting
>>>>>>>> from
>>>>>>>> the top.
>>>>>>>> The only other locals could be function arguments, and
>>>>>>>> instnamer
>>>>>>>> names those too.
>>>>>>>>
>>>>>>>>
>>>>>>>> So there really is no way to do this shy of
>>>>>>>> creating (or
>>>>>>>> basically
>>>>>>>> copying) the API from AsmWriter (seems very dedundant
>>>>>>>> to
>>>>>>>> me)?
>>>>>>>> This seems
>>>>>>>> like a large failing?
>>>>>>>>
>>>>>>>>
>>>>>>>> Correct, you'd have to copy that logic.
>>>>>>>>
>>>>>>>> It's not a large failing because nobody uses names of
>>>>>>>> non-globals
>>>>>>>> for anything. When we want to refer to a value, we use
>>>>>>>> the
>>>>>>>> Value*.
>>>>>>>>
>>>>>>>> Nick
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Oct 21, 2011 at 7:03 PM, Nick Lewycky
>>>>>>>> <nicholas at mxc.ca <mailto:nicholas at mxc.ca>
>>>>>>>> <mailto:nicholas at mxc.ca <mailto:nicholas at mxc.ca>>
>>>>>>>> <mailto:nicholas at mxc.ca <mailto:nicholas at mxc.ca>
>>>>>>>> <mailto:nicholas at mxc.ca <mailto:nicholas at mxc.ca>>>> wrote:
>>>>>>>>
>>>>>>>> Ryan Taylor wrote:
>>>>>>>>
>>>>>>>> It looks like the AsmWriter is generating the
>>>>>>>> local
>>>>>>>> variables
>>>>>>>> (SlotNum)s
>>>>>>>> on the fly in that file (AsmWriter.cpp), so
>>>>>>>> is
>>>>>>>> there any
>>>>>>>> way at
>>>>>>>> all to
>>>>>>>> get this information from the operation
>>>>>>>> itself, via
>>>>>>>> Instruction,
>>>>>>>> Value
>>>>>>>> or Type?
>>>>>>>>
>>>>>>>>
>>>>>>>> Nope! As you noticed, they're created on the
>>>>>>>> fly...
>>>>>>>>
>>>>>>>> ...when the Value or Type is anonymous. If you
>>>>>>>> want
>>>>>>>> them to be
>>>>>>>> persistent, values can have names via. the
>>>>>>>> setName()
>>>>>>>> call. "opt
>>>>>>>> -instnamer" will name all your instructions, for
>>>>>>>> example.
>>>>>>>>
>>>>>>>> Nick
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111024/d9e44ceb/attachment.html>
More information about the llvm-dev
mailing list