[LLVMdev] Question about local variables
Nick Lewycky
nlewycky at google.com
Mon Oct 24 11:48:37 PDT 2011
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/4a74f6fe/attachment.html>
More information about the llvm-dev
mailing list