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? On Fri, Oct 21, 2011 at 7:03 PM, Nick Lewycky <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/20111022/d9b7d682/attachment.html>
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>> 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 > >
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? On Sat, Oct 22, 2011 at 12:51 PM, Nick Lewycky <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>> 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/20111022/913737b4/attachment.html>
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.bcAlmost, 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>> 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>>> 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 > > > >
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 > > > > > >
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>
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/4a74f6fe/attachment.html>
[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>
On 24 October 2011 15:50, Ryan Taylor <ryta1203 at gmail.com> wrote:> 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 On Mon, Oct 24, 2011 at 3:43 PM, Nick Lewycky <nlewycky at google.com> wrote:> >> [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/d9e44ceb/attachment.html>
janarbek
2011-Oct-24 23:27 UTC
[LLVMdev] LLVM build is failed giving Path.inc:714: error: ‘unlink’ was not declared in this scope
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 at ubuntu:~/Work/llvm/llvm_obj$ vi ../llvm/lib/Support/Path.cpp -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111024/fab7caff/attachment.html>
Maybe Matching Threads
- [LLVMdev] LLVM build is failed giving Path.inc:714: error: ‘unlink’ was not declared in this scope
- [LLVMdev] LLVM build is failed giving Path.inc:714: error: ‘unlink’ was not declared in this scope
- [LLVMdev] LLVM build is failed giving Path.inc:714: error: ‘unlink’ was not declared in this scope
- [LLVMdev] LLVM build is failed giving Path.inc:714: error: ‘unlink’ was not declared in this scope
- [LLVMdev] LLVM build is failed giving Path.inc:714: error: ‘unlink’ was not declared in this scope