[LLVMdev] Question about local variables

[Nick Lewycky]

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
>
>
>
>
>
>