similar to: [LLVMdev] Cannot get Alias Analysis?

Hi, How can I use profile information into my pass for performing some analysis. I tried something like: PassManager PassMgr = PassManager(); cl::opt<std::string> ProfileDataFile(cl::Positional, cl::desc("<llvmprof.out file>"), cl::Optional, cl::init("llvmprof.out")); PassMgr.add(createProfileLoaderPass(ProfileDataFile));

The following code is causing an "UNREACHABLE executed!" and a stack dump, any ideas? namespace { struct myPass : public CallGraphSCCPass { static char ID; myPass() : CallGraphSCCPass(ID) {} virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesAll(); AU.addRequired<LoopInfo>(); } virtual bool runOnSCC(CallGraphSCC &SCC)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I try to write a tool that uses the PassManager to load profiling information for a module like this: ... ModulePass *LoaderPass = createProfileLoaderPass(); PassMgr.add(LoaderPass); PassMgr.run(*M); ... I can verify that the pass was run, but how to I get to the ProfileInfo implemented by that pass? I tried ... ProfileInfo PI =

I'm building a SCCPass below, it appears that the CallGraphNode->getFunction returns a valid function but seg faults on call like "getName" or "size" but not on calls like "empty" (which returns false). My understanding is that the heirarchy is: CallGraphSCC->CallGraphNode->Function->BasicBlock->Instruction, is this not the case? virtual bool

On Tue, Nov 29, 2011 at 6:59 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > The following code is causing an "UNREACHABLE executed!" and a stack dump, > any ideas? The stack might be handy. > namespace { >   struct myPass : public CallGraphSCCPass { >   static char ID; >   myPass() : CallGraphSCCPass(ID) {} >   virtual void getAnalysisUsage(AnalysisUsage

UNREACHABLE executed! 0 opt 0x00000000008edc2f 1 opt 0x00000000008edfda 2 libpthread.so.0 0x00007f9c8e69bc60 3 libc.so.6 0x00007f9c8d986d05 gsignal + 53 4 libc.so.6 0x00007f9c8d98aab6 abort + 390 5 opt 0x00000000008da974 llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) + 356 6 opt 0x000000000087e046 7 opt

Hi, List, As you may know, BCC of android makes use of LLVM's major components. Its LTO actually selects some optimizations of LLVM. I found it can not only use "-functionattrs". I must first use -argpromotion first, or I end up this error: Pass 'Deduce function attributes' is not initialized. Verify if there is a pass dependency cycle. Required Passes: bcc:

I have not made a separate pass. I have done it in single pass ie added ProfileLoaderPass , got information in PI and now I am planning to perform the analysis here itself. I was trying to print information using ProfileInfoPrinter pass but was unable to do it. namespace { class MyAna : public ModulePass { ProfileInfo *PI; public: static char ID; // Class identification, replacement

In addition to the link below, please check for functions like "llvm.debug.declare", "llvm.debug.value", as you will not get LoopInfo for these.   Pankaj   ________________________________ From: Devang Patel <dpatel at apple.com> To: Ryan Taylor <ryta1203 at gmail.com> Cc: llvmdev at cs.uiuc.edu Sent: Wednesday, November 30, 2011 11:08 PM Subject: Re: [LLVMdev]

Thanks for the info. Curious, do you know if there is an opt that will put all loops, including nested ones, in functions (ie each loop in it's own function)? What I'm trying to do is create a way for each loop to have only one exit. I want all loops to be single exit loops? I can write my own pass but I'd rather not. I think that if I can put each loop into it's own function

We can't simply free the connector after calling drm_connector_init on it. We need to clean up the drm side first. It might not fix all regressions from 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts"), but at least it fixes a memory corruption in error handling related to that commit. Link:

Just special case DP DSM connectors until we properly figure out how to deal with this. This resolves user regressions on GPUs with such connectors without reverting the original fix. Cc: Lyude Paul <lyude at redhat.com> Cc: stable at vger.kernel.org # 6.4+ Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/255 Fixes: 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for

Hi Alexander, I had the same error: sincos: /home/marcusmae/rpmbuild/BUILD/llvm/lib/VMCore/PassManager.cpp:635: void llvm::PMTopLevelManager::schedulePass(llvm::Pass*): Assertion `PI && "Expected required passes to be initialized"' failed. The solution was to add: PassRegistry &Registry = *PassRegistry::getPassRegistry(); initializeCore(Registry);

Dear lazydev, I'm writing an instrumentation pass that depends on AliasAnalysis. My getAnalysisUsage() looks as follows: 2453 void ThreadSanitizer::getAnalysisUsage(AnalysisUsage &AU) const { 2454 AU.addRequired<TargetData>(); 2455 AU.addRequired<AliasAnalysis>(); 2456 } and the pass initialization: 2668 char ThreadSanitizer::ID = 0; 2669

On 10/30/2012 4:10 PM, Ashwin kumar wrote: > > Assertion failed: (PI && "Expected required passes to be initialized"), > function schedulePass, file PassManager.cpp, line 597. > > > I register the passes using RegisterPass function call. What else should > I be doing? Initializing them. Are you using INITIALIZE_PASS_DEPENDENCY, INITIALIZE_AG_DEPENDENCY,

On Oct 30, 2012, at 3:15 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 10/30/2012 4:10 PM, Ashwin kumar wrote: >> >> Assertion failed: (PI && "Expected required passes to be initialized"), >> function schedulePass, file PassManager.cpp, line 597. >> >> >> I register the passes using RegisterPass function call.

I am trying to add an analysis pass as a FunctionPass, and let LICM (LoopPass) depends upon it. So in LICM.cpp, I have the following: virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesCFG(); AU.addRequired<DominatorTree>(); AU.addRequired<LoopInfo>(); AU.addRequiredID(LoopSimplifyID); AU.addRequired<AliasAnalysis>();

>> If you write your code as an llvm pass, you should automatically get >> notified of this stuff in a debug build. If you can't do that, >> manually interfacing to the LeakDetector can help. >> > It is an LLVM pass, it's a debug build, and the only assertion I got > was > the one in ~Value(). > > Should there have been an earlier assertion? You

Chris Lattner wrote: >>> If you write your code as an llvm pass, you should automatically get >>> notified of this stuff in a debug build. If you can't do that, >>> manually interfacing to the LeakDetector can help. >>> >>> >> It is an LLVM pass, it's a debug build, and the only assertion I got >> was >> the one in

On Oct 27, 2008, at 3:14 AM, Jay Foad wrote: >>> I'm already working on this myself. Would you be interested in >>> having >>> this work contributed back to LLVM? >> >> If this were to better support target independent languages, it would >> be very useful. If you're just trying to *reduce* the endianness >> assumptions that leak