similar to: [LLVMdev] Scope and symbol table

subramanyam wrote: > > Hi all, > I have a question regarding populating ValueSymbolTable of a Function. > Is it that ValueSymbolTable is populated automatically whenever an alloca > instruction is created using IRBuilder or do we need to explicitly > populate?? It's maintained by LLVM for you, by Value::setName and other methods. Nick

Nick Lewycky wrote: > > > > It's maintained by LLVM for you, by Value::setName and other methods. > > Nick > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > I am getting the following error when trying to

It is possible to change the name of a Function with Value::setName, so this patch _could_ cause incorrect answers. You should add a test that calls setName("intrinsic.name") to make sure this keeps working, regardless of where this patch goes. You might be able to catch such events in the ValueSymbolTable and update the intrinsic ID, but I can't find an obvious place to put that

Hi all, I have a question regarding populating ValueSymbolTable of a Function. Is it that ValueSymbolTable is populated automatically whenever an alloca instruction is created using IRBuilder or do we need to explicitly populate?? If we need to populate explicitly, the insert method in ValueSymbolTable is private, so how can we do it? Currently, I am trying to access the symbol table as below:

Hi, I want to implement a simple common sub expression pass in llvm2.8 which demands replacing the uses of the redundant expressions with a temporary variable. So, to introduce new temporary variable I have inserted an AllocaInst (...) providing the name of the temporary and desired type. But whenever I am going to insert a LoadInst for that variable I am getting segmentation fault. It is

Hi Jeffrey, Please correct me if I'm wrong, but I believe a test that checks for the old behavior would be pointless. I realize that my patch would return an unmatching intrinsicID when the function's name changes, but the real question we should ask is do we really want to be able to change the intrinsicID by changing the function's name? Also, the original Function constructor

Hi llvm-dev, Our code base has a ancient copy of llvm (ver 3.5.1), and it uses the LLVM code gen for some domain-specific language. The previous dev left a global lock around the usage of LLVM code gen stating that because LLVM code gen can only be accessed single-threaded it needs to be protected with this global lock. But now this lock has caused some perf issues as we pretty much lose

On Fri, May 27, 2016 at 8:48 AM, Rafael Espíndola <llvm-dev at lists.llvm.org> wrote: > This is about https://llvm.org/bugs/show_bug.cgi?id=27551. > > Currently there is no easy way to get symbol information out of > bitcode files. One has to read the module and mangle the names. This > has a few problem > This would be great for ThinLTO as well: > > * During lto

Hi Chris, I was thinking that CreateValueName() was the way to add a symbol to a symbol table. Perhaps I'm thinking about this wrong. Here's what I've got: I've got a string generated by the parser which is constant. I need to add it to the symbol table so that, on starting the second pass of my compiler, I can dump all of the string constants to be generated as code. I

Thank you Johannes, I looked it up and it seems that we're creating one LLVMContext per compilation "unit", not sure if that matters. i.e. there's no single globally shared LLVMContext object. Is LLVMContext *the* concurrency isolation (or unit) here? On Wed, Apr 3, 2019 at 6:34 PM Doerfert, Johannes <jdoerfert at anl.gov> wrote: > Do you use one llvm context or one

On Jul 9, 2010, at 12:02 PM, Samuel Crow wrote: > Hello, > > Why are ValueSymbolTable's mutators all private? I can't seem to find a way to > add a symbol to the table without using one of them. It looks like a bug to me > since there is no way to use it otherwise. The mutators are things like Value::setName() -Chris

Hi all, I just walked across an interesting situation in Module::getOrInsertFunction(Name, Type) in the LLVM C API. In my particular case: One of the first things we do is add a global variable named foo which is a [ 100 x i64 ]. Later we add a function void foo(...) unfortunately, when we do the getOrInsertFunction we get back void (...) * bitcast ([100 x i64]* @foo_ to void (...)*)

Hello, I'm using llvm 2.5. I initially built it with GCC 4.1.2 and it completed building. But when I run it with a simple test function, it fails with the following issue: Value still in symbol table! Type = 'i32' Name = 'a' Value still in symbol table! Type = 'i32' Name = 'b' llc: ValueSymbolTable.cpp:29: llvm::ValueSymbolTable::~ValueSymbolTable():

Do the buildbots only build debug components? I am seeing lots of this on trunk with release-style builds: [x86_64-off-opt]: Failed with signal(SIGABRT) at line 1 [x86_64-off-opt]: while running: llvm-as < /ptmp/dag/llvm- project.official/llvm/tags/RELEASE_25/test/Transforms/TailDup/basictest2.ll | opt -tailduplicate -disable-output [x86_64-off-opt]: Value still in symbol table! Type =

June Status Update ------------------ Hi everyone, Since the last status update, we've had a lot of progress on various fronts. In particular, we passed the 15,000th commit to the llvm-commits list, we have some great new features and documentation, new people using LLVM, and (strangely enough) the MachineBasicBlock class seems to have received a lot of love. At this point, I'm

No, some build release, and some build release-asserts. Historically, this is a typical sign of llvm being miscompiled, see the broken-gcc list. - Daniel On Mon, Feb 15, 2010 at 10:09 AM, David Greene <dag at cray.com> wrote: > Do the buildbots only build debug components?  I am seeing lots of this on > trunk with release-style builds: > > [x86_64-off-opt]: Failed with

Hi, I've just tried out version 2.4, and it doesn't work for me in situations where 2.3 seems fine. The current trunk code appears to have the same problem. When I compile a simple program in llvm-gcc, I get a .bc file as output as expected. When running lli or llc on this file, however, I get various errors and an assert, stopping the .s file from being created. Example output of llc:

Hi All, I need to implement something like a variable for each basic block How to implement lookup table in LLVM , I think ValueSymbolTable is closest one but how could I do that by it -- * Rasha Salah Omar Msc Student at E-JUST Demonestrator at Faculty of Computers and Informatics Benha University* * e-mail: rasha.omar at ejust.edu.eg* P* Please consider the

Adding llvm-dev as that might be a more suitable audience for this discussion. (& I know Lang's been playing around with the same problem in the Orc JIT, so adding him too) Is there any basis/reason to believe that the .X suffix is a better, more principled one than straight X? Is that documented somewhere as a thing the demangling tools will ignore? On Tue, Apr 14, 2015 at 12:06 PM,

Hi, I've been writing some optimization passes for LLVM and had good luck with the simple stuff, but I am running into all kinds of trouble trying to make copies of variables within a BasicBlock as part of a LoopPass I am trying to make copies of the variables that are in scope in the loop body like so: //Remove the existing terminator