[LLVMdev] Accessing instruction/operand names

Jeffrey Yasskin jyasskin at google.com
Wed Apr 15 08:43:43 PDT 2009


The other repliers have been right that you probably want to use
Value*s rather than string names in constructing your dependency
graph, but I wanted to clear up a second possible point of confusion.
When you see %2 in the assembly, that's an indication that the
instruction's name is empty. That is, value->getName() == "". As far
as I know, llvm-dis just generates numbers in order for un-named
instructions. When the instruction has a name (value->getName() ==
"the_name"), you get %the_name instead of the number. Does that make
sense?

On Wed, Apr 15, 2009 at 6:20 AM, James Stanier <j.stanier at sussex.ac.uk> wrote:
>
> Hello everyone,
>
> I'm currently constructing a graph from LLVM bitcode, and I have a question
> about accessing the names of the variables shown in the .ll assembly file,
> assuming it's possible...
>
> For example, with
>
> %2 = load i32* %x_addr, align 4         ; <i32> [#uses=1]
>
> I can retrieve the opcodeName() from the Instruction object, which is
> "load". I can also access the operand and use getName() to retrieve
> "x_addr". However, this instruction is storing into %2 - how do I access the
> name of that?
>
> Also, when an operand is a numbered temporary such as
>
> %3 = add i32 %2, %1             ; <i32> [#uses=1]
>
> I'm also unable to access the name of it. Are these numberings no longer
> present in the bitcode? If not, is there any way to find out the name of
> which local variable it is referencing?
>
> Thanks in advance - I've been stuck on this for a while.
>
> Best,
>
> James
> --
> View this message in context: http://www.nabble.com/Accessing-instruction-operand-names-tp23058683p23058683.html
> Sent from the LLVM - Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>




More information about the llvm-dev mailing list