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