similar to: [LLVMdev] Problem using ilist container

Dear all, The below has been tested quite thoroughly by now, including performance-testing by the way of using a modified compiler that triggers the below while compiling at least an old part of LLVM ["Function.cpp"] and sorting a symbol table with >7000 global variables. Unfortunately, the optimization I have been working on for which I _thought_ I needed the ability to sort a

Hi, Today I've been trying to debug a weird bug that makes JIT crash with certain code and when using the inliner. This may sound weird, but if I disable the inliner, it doesn't crash. I include an example gdb dump below. Does something looks wrong? Do you think it's a bug in JIT or it's just some other piece of code that is writing on the JIT memory?.. I don't really know

Hi llvm-devel, I have migrated my codebase from llvm-3.6 to llvm 3.8.1-stable. Although I was able to resolve most of the problems, I am facing issues resolving the following: To insert an instruction immediately after the first instruction within a basic block, I first get all instructions in my basic block in an instruction container list. Once that is done, I insert my new instruction in the

"Duncan P. N. Exon Smith via llvm-dev" <llvm-dev at lists.llvm.org> writes: >> On 2015-Oct-20, at 11:23, Reid Kleckner <rnk at google.com> wrote: >> >> I think the implicit iterator conversions are much less important >> now that we have range based for loops, but I still like having >> them. > > IMO, if a developer has an ilist iterator

I am using LLVM 2.6 and I have a question on the use of the BasicBlock::iterator to hoist loop invariant instructions to the loop preheader. When I process the instructions backward as shown in the following code, I got the following error right after the "hoist(I)" is done. Can anyone advise whether I am misusing BasicBlock::iterator? /opt/llvms/src/llvm_26/

I've been digging into some undefined behaviour stemming from how ilist is typically configured. r247937, r247944, and r247978 caused a UBSan failure to start firing on our Green Dragon bots, and after an IRC conversation between David and Nick and Mehdi, we added a blacklist: -- $echo "src:$WORKSPACE/llvm/include/llvm/CodeGen/MachineFunction.h" >> sanitize.blacklist --

Hi all, I am finding a SEGFAULT in one of my passes when using getPrevNode on an instruction that is the only one in a BasicBlock. I was expecting getPrevNode to return 0 in that case (as per docs), but it breaks. I guess the code in in ilist_node.h: NodeTy *getPrevNode() { NodeTy *Prev = this->getPrev(); // Check for sentinel. if (!Prev->getNext()) return 0; return Prev; }

Using Valgrind hasn't shown me anything terribly unusual. And I'm confused because its not even trying to delete a real instruction; deleting a void type with no name? That doesn't make any sense... Any other hints? I've seen a few posts in the past about this relating to some internal LLVM bugs... -Griffin On Thu, 12 Jan 2012 21:26:41 +0100, Duncan Sands <baldrick at

Yes, it is a pass. Here is a very general overview of the file structure as far as the AA is concerned. LLVM is not my strong-suit, I do hardware simulators, not compilers. using namespace llvm; char RelRecovery::ID = 0; static RegisterPass<RelRecovery> X("relRecovery", "Reliability transformation for lightweight recovery"); void

Hi Griffin, did your pass create a data structure that holds values somehow, and forgot to delete it? Also, try running under valgrind in case this is due to a memory error of some kind. Ciao, Duncan. > So I have an LLVM pass that appears to run completely and work fine, and > then it aborts at the very end. When exiting the final runOnFunction call, > I get the following error /

Hello all, I am working with someone else's LLVM code, which is about 8 months old. Part of this pass involves AliasAnalysis, and I'm getting the above assertion when the pass completes. The dump is as follows: -------------------------------- Program received signal SIGABRT, Aborted. 0xf7fdf430 in __kernel_vsyscall () (gdb) bt #0 0xf7fdf430 in __kernel_vsyscall () #1 0xf602e921 in

Hello, I've been stuck with a problem for about a month, and it has stumped everyone in my lab. I have a function pass that runs, and when it finishes and opt goes to return, I get: While deleting: void % An asserting value handle still pointed to this value! UNREACHABLE executed at /x/grwright/llvm/llvm-2.9/lib/VMCore/Value.cpp:569! On a simple test case, the error becomes 'i32 %'

Hey everyone, So I have an LLVM pass that appears to run completely and work fine, and then it aborts at the very end. When exiting the final runOnFunction call, I get the following error / stack dump. I cannot figure out why this is happening for the life of me - does anyone have any ideas? I'm not trying to do any crazy deallocation or anything, it just seems like a normal pass to me.

Xia, LLVM doesn't really use type qualifiers the way you're thinking about it. In LLVM parlance, types are neither const nor non-const, they just define the fundamental nature of a value. However, LLVM fully supports Constant Values (see include/llvm/Constant.h) and constant global variables (see include/llvm/GlobalVariable.h). You might want to read up on the LLVM IR a bit here:

Hi Jacob, At this point, I suspect there is a problem with maintaining liveness information during branch folding. Here is what I see: I have a basic block ready for branch optimization, that computes a predicate p10 on which a conditional branch depends. Notice that this is in the stage with physical registers. BB#2: derived from LLVM BB %while.cond.preheader Live Ins: %R3 %R5

Hi Has anybody tell me how to create some new type qualifies in LVM? A type qualify, like "const" in C, is useful for program analysis. I hope that I can set/get the type qualify of any value in a program analysed. Or, if I could add a property to the value class and set/get the property, it is same to add some new type qualifies. So, I simply insert a "int" private

Griffin Wright wrote: > > Hello all, > > I really, really, really need your help. This is my third email now, > please don't ignore me! I understand this must be a trivial thing, but > I've ground to a halt, and REALLY need some guidance. Please see below for > the context of my problem. I'm not trying to be a waste of time, but I'm > desperate here.

I think the implicit iterator conversions are much less important now that we have range based for loops, but I still like having them. On Tue, Oct 20, 2015 at 11:13 AM, Duncan P. N. Exon Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On 2015-Oct-07, at 17:57, Duncan P. N. Exon Smith <dexonsmith at apple.com> > wrote: > > > > I've been

Hello all, I really, really, really need your help. This is my third email now, please don't ignore me! I understand this must be a trivial thing, but I've ground to a halt, and REALLY need some guidance. Please see below for the context of my problem. I'm not trying to be a waste of time, but I'm desperate here. I have a getAnalysisUsage method which does the following

Hi, Thank Brian Gaeke so much. Following TraceBasicBlocks.cpp, I modified the code as below and could insert instruction or function I need into anywhere in Module. But it works well without BB->getInstList().push_back(InstrCall), and if I add the BB->getInstList().push_back() following new CallInst(), I got error information when runing opt. What is the reason for it? And is it necessary