Question about local variables

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?

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

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.

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?

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

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?

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

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?

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". :slight_smile:

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

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

Nick,

Is there a clean way to tell the difference between dst and src operands in operations without assignment “=” (ie, store)?

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

[please remember to cc llvmdev]

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

Nick,

Oh, sorry. So there are lots of “void” operations, I basically just want to print out the operation name, it’s dest operands and source operands,

What’s a dest operand? The term “operand” in LLVM always refers to the inputs (ie., an add has two operands).

that’s it, I was just hoping for a cleaner interface to this information. It doesn’t sound like there is one.

Overall, I’m just trying to extract, the operation name, the source operands, the dest operands along with dst and src widths/signs, etc.

Looking at “%x = add i32 %y, 1” the pieces here are:

“%x” the name of the instruction (I->getName())
“add” the instruction opcode (I->getOpcodeName())
“i32” the first operand type (I->getOperand(0)->getType())
“%y” the first operand (I->getOperand(0)->getName())
“1” the second operand (type is implicit here because a binop needs the same type on both sides). (I->getOperand(1))

LLVM integer types are signless, so I can’t help you there.

Nick

Hello All,

I am getting following error on Ubuntu. My gcc is gcc version 4.4.5. Please let me know if you have any comments/suggestions.

In file included from /home/janarbek/Work/llvm/llvm/lib/Support/Path.cpp:299:
/home/janarbek/Work/llvm/llvm/lib/Support/Unix/Path.inc: In member function ‘bool llvm::sys::Path::eraseFromDisk(bool, std::string*) const’:
/home/janarbek/Work/llvm/llvm/lib/Support/Unix/Path.inc:714: error: ‘unlink’ was not declared in this scope
make[1]: *** [/home/janarbek/Work/llvm/llvm_obj/lib/Support/Release+Asserts/Path.o] Error 1
make[1]: Leaving directory `/home/janarbek/Work/llvm/llvm_obj/lib/Support’
make: *** [all] Error 1
janarbek@ubuntu:~/Work/llvm/llvm_obj$ vi …/llvm/lib/Support/Path.cpp


|

Does the attached patch help?

Does this issue show up with 3.0 RC1? (http://llvm.org/pre-releases/3.0/)

-Eli

unistd.txt (346 Bytes)

I am not sure if I applied correctly.I did following and it seems failed.

janarbek@ubuntu:~/Work/llvm$ patch <unistd.txt
patching file Path.inc
Hunk #1 FAILED at 51.
1 out of 1 hunk FAILED – saving rejects to file Path.inc.rej





===========================================

Phone : 82-42-860-1838
Fax : 82-42-860-6790
Cell Phone: 82-10-7599-1981
===========================================


— On Mon, 10/24/11, Eli Friedman eli.friedman@gmail.com wrote:


> From: Eli Friedman eli.friedman@gmail.com
> Subject: Re: [LLVMdev] LLVM build is failed giving Path.inc:714: error: ‘unlink’ was not declared in this scope
> To: “janarbek” canarbekmatay@yahoo.com
> Cc: “LLVM Developers Mailing List” llvmdev@cs.uiuc.edu
> Date: Monday, October 24, 2011, 4:36 PM
>
> On Mon, Oct 24, 2011 at 4:27 PM, janarbek canarbekmatay@yahoo.com wrote:
> >
> > Hello All,
> >
> > I am getting following error on Ubuntu. My gcc is gcc version 4.4.5. Please let me know if you have any comments/suggestions.
> >
> > In file included from /home/janarbek/Work/llvm/llvm/lib/Support/Path.cpp:299:
> > /home/janarbek/Work/llvm/llvm/lib/Support/Unix/Path.inc: In member function ‘bool llvm::sys::Path::eraseFromDisk(bool, std::string*) const’:
> > /home/janarbek/Work/llvm/llvm/lib/Support/Unix/Path.inc:714: error: ‘unlink’ was not declared in this scope
> > make[1]: *** [/home/janarbek/Work/llvm/llvm_obj/lib/Support/Release+Asserts/Path.o] Error 1
> > make[1]: Leaving directory `/home/janarbek/Work/llvm/llvm_obj/lib/Support’
> > make: *** [all] Error 1
> > janarbek@ubuntu:~/Work/llvm/llvm_obj$ vi …/llvm/lib/Support/Path.cpp
>
> Does the attached patch help?
>
> Does this issue show up with 3.0 RC1? (http://llvm.org/pre-releases/3.0/)
>
> -Eli

|

Try "patch -p0 < unistd.txt".

-Eli

Nope,

It is giving same error. I got source from svn. Assuming this is current version which might have bugs, shall I try 2.9 version ?




===========================================

Phone : 82-42-860-1838
Fax : 82-42-860-6790
Cell Phone: 82-10-7599-1981
===========================================


— On Mon, 10/24/11, Eli Friedman eli.friedman@gmail.com wrote:


> From: Eli Friedman eli.friedman@gmail.com
> Subject: Re: [LLVMdev] LLVM build is failed giving Path.inc:714: error: ‘unlink’ was not declared in this scope
> To: “janarbek” canarbekmatay@yahoo.com
> Cc: “LLVM Developers Mailing List” llvmdev@cs.uiuc.edu
> Date: Monday, October 24, 2011, 4:47 PM
>
> On Mon, Oct 24, 2011 at 4:41 PM, janarbek canarbekmatay@yahoo.com wrote:
> >
> > I am not sure if I applied correctly.I did following and it seems failed.
> >
> > janarbek@ubuntu:~/Work/llvm$ patch <unistd.txt
> > patching file Path.inc
> > Hunk #1 FAILED at 51.
> > 1 out of 1 hunk FAILED – saving rejects to file Path.inc.rej
>
> Try “patch -p0 < unistd.txt”.
>
> -Eli

|


I apply patch, it says patch is applied. Does the directory which I run patch matters ?




===========================================

Phone : 82-42-860-1838
Fax : 82-42-860-6790
Cell Phone: 82-10-7599-1981
===========================================


— On Mon, 10/24/11, Eli Friedman eli.friedman@gmail.com wrote:


> From: Eli Friedman eli.friedman@gmail.com
> Subject: Re: [LLVMdev] LLVM build is failed giving Path.inc:714: error: ‘unlink’ was not declared in this scope
> To: “janarbek” canarbekmatay@yahoo.com
> Cc: “LLVM Developers Mailing List” llvmdev@cs.uiuc.edu
> Date: Monday, October 24, 2011, 4:47 PM
>
> On Mon, Oct 24, 2011 at 4:41 PM, janarbek canarbekmatay@yahoo.com wrote:
> >
> > I am not sure if I applied correctly.I did following and it seems failed.
> >
> > janarbek@ubuntu:~/Work/llvm$ patch <unistd.txt
> > patching file Path.inc
> > Hunk #1 FAILED at 51.
> > 1 out of 1 hunk FAILED – saving rejects to file Path.inc.rej
>
> Try “patch -p0 < unistd.txt”.
>
> -Eli

|

I apply patch, it says patch is applied. Does the directory which I run patch matters ?

You should be running the "patch -p0 < unistd.txt" in the root LLVM
source directory for the trunk version. If you're still getting "Hunk
#1 FAILED at 51." errors, you're not doing that.

-Eli

Yes,

I applied the patch on trunk version like below. It says patching file. However, when I make, the build is still failing.

janarbek@ubuntu:~/Work/llvm/llvm$ patch -p0 < unistd.txt
patching file lib/Support/Unix/Path.inc






===========================================

Phone : 82-42-860-1838
Fax : 82-42-860-6790
Cell Phone: 82-10-7599-1981
===========================================


— On Mon, 10/24/11, Eli Friedman eli.friedman@gmail.com wrote:


> From: Eli Friedman eli.friedman@gmail.com
> Subject: Re: [LLVMdev] LLVM build is failed giving Path.inc:714: error: ‘unlink’ was not declared in this scope
> To: “janarbek” canarbekmatay@yahoo.com
> Cc: “LLVM Developers Mailing List” llvmdev@cs.uiuc.edu
> Date: Monday, October 24, 2011, 5:04 PM
>
> On Mon, Oct 24, 2011 at 4:58 PM, janarbek canarbekmatay@yahoo.com wrote:
> >
> > I apply patch, it says patch is applied. Does the directory which I run patch matters ?
>
> You should be running the “patch -p0 < unistd.txt” in the root LLVM
> source directory for the trunk version. If you’re still getting “Hunk
> #1 FAILED at 51.” errors, you’re not doing that.
>
> -Eli
>
> >
> >
> > ===========================================
> > Phone : 82-42-860-1838
> > Fax : 82-42-860-6790
> > Cell Phone: 82-10-7599-1981
> > ===========================================
> >
> > — On Mon, 10/24/11, Eli Friedman eli.friedman@gmail.com wrote:
> >
> > From: Eli Friedman eli.friedman@gmail.com
> > Subject: Re: [LLVMdev] LLVM build is failed giving Path.inc:714: error: ‘unlink’ was not declared in this scope
> > To: “janarbek” canarbekmatay@yahoo.com
> > Cc: “LLVM Developers Mailing List” llvmdev@cs.uiuc.edu
> > Date: Monday, October 24, 2011, 4:47 PM
> >
> > On Mon, Oct 24, 2011 at 4:41 PM, janarbek canarbekmatay@yahoo.com wrote:
> > >
> > > I am not sure if I applied correctly.I did following and it seems failed.
> > >
> > > janarbek@ubuntu:~/Work/llvm$ patch <unistd.txt
> > > patching file Path.inc
> > > Hunk #1 FAILED at 51.
> > > 1 out of 1 hunk FAILED – saving rejects to file Path.inc.rej
> >
> > Try “patch -p0 < unistd.txt”.
> >
> > -Eli

|

That means it was applied.

In that case, I have no idea how you could run into the error you're
seeing; unlink should be defined in unistd.h.

-Eli