[LLVMdev] Question about local variables
Ryan Taylor
ryta1203 at gmail.com
Mon Oct 24 10:31:29 PDT 2011
Nick,
Is there a clean way to tell the difference between dst and src operands
in operations without assignment "=" (ie, store)?
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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111024/a8547013/attachment.html>
More information about the llvm-dev
mailing list