similar to: [LLVMdev] Assertion `AA && "AA didn't call InitializeAliasAnalysis in its run method!"' failed.

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

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

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.

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.

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 /

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

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 all, So I've been working to fix a problem I had wherein I could not properly initialize AliasAnalysis profiling information. In order to fix it, I've had to rewrite how my pass operates, such that it contains this in the FunctionPass declaration; RelRecovery() : FunctionPass(ID) { llvm::initializeRelRecoveryPass(*PassRegistry::getPassRegistry()); } and contains these

Hello: I recently attempted to update the ARM cross-compilation setup I had with llvm, and it did not work, so I wanted to revert back to my initial configuration. I reconfigured/make/make install'ed my llvm which executed fine, and then cleared out my llvm-gcc obj and install folders, and reconfigured gcc from within llvm-gcc/obj as follows: ../llvm-gcc-4.2-2.9.source/configure

Guys, In this case, I wanted to hack globalopt pass to require ScalarEvolution analysis. It seems ScalarEvolution is not released after globalopt pass, and it will hold a reference to the basicblocks. Later when the function is removed(by inline pass), coredump happened: opt test.bc -mem2reg -globalopt -inline -loop-unroll -debug-pass Details -o out.bc >& log So it seems to me if a pass

I have ran under valgrind memcheck the process using libLLVM-2.9.so (rev.126022) and got several errors: ==24227== Invalid read of size 1 ==24227== at 0x40274C9: memcpy (mc_replace_strmem.c:497) ==24227== by 0x40D5B84: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in

Hi All, I have just started using LLVM . i am facing a issue while using ilist container. Here is a struct with ilist container as its one element. typedef ilist<Instruction *> InstListType; struct list_node { int Impact; InstListType InstList; }; list_node

On Fri, Feb 3, 2012 at 1:20 PM, Griffin Wright <grwright at umich.edu> wrote: > > 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! >

ValGrind gives me some info, but I'm not great at memory stuff, and so I'm not sure what to make of it... This is code that worked for someone 8 months ago, and I'm just trying to get it to run on llvm 2.9 instead of 2.8, so the fact that it hasn't been working is frustrating. Anyway, my issues seem to stem from IntervalIterator, as seen below. I have a lot of similar issues

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, Griffin > /net/coldwater/w/grwright/Research/llvm/arm-2010q1/bin/arm-none-linux-gnueabi-as: ^^^^^^^^^^^ Maybe using a newer codesourcery toolchain can help you? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667

Dear LLVMers, I need help with one error in my register allocator. I am getting errors when folding instructions for the x86 (it does not happen when I use the PowerPC as target). The problem is that, when I execute something like: mi = mbb->insert(mbb->erase(mi), fmi), where mbb is a MachineBasicBlock, valgrind gives this error message: Address 0x42C62B0 is 24 bytes inside a block

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

I'm working on a pass (both LLVM and the pass have been compiled in debug+asserts mode) but when the pass crashes in the stack trace printed by opt the names of the functions inside my pass don't appear (see frames 14-16). How can I have them displayed? > cafxx at ubuntu:~/Projects/llvm2/Debug+Asserts/bin$ clear && ./opt > -load=CGF.so -cgf -debug test.S > [...] >

----- Original Message ----- > From: "Hal Finkel" <hfinkel at anl.gov> > To: "Chandler Carruth" <chandlerc at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Daniel Berlin" <dannyb at google.com> > Sent: Thursday, July 2, 2015 3:14:38 PM > Subject: Re: AliasAnalysis update interface - a tale