similar to: [LLVMdev] Profile Info with Machine Function Pass Fails

Hi all, I am trying to load a profile information (llvmprof.out) which has been separately created, to get the execution count of each basic block and use it to estimate the execution count of machine basic blocks for getting how many times any instruction gets executed, for ARM specifically. The error on running the code comes as: clang: PassManager.cpp:601: void

Hi, I am trying to run a profiling pass for each Machine Basic Block so that I can get execution count for them, but I am getting assertion error when I run it through clang. I have used MachineProfileInfo and Profile estimator as dependent passes over my pass. I am sending you the code for my pass. the error says: void llvm::PMTopLevelManager::schedulePass(llvm::Pass*): Assertion `PI &&

Hi, We use LLVM libraries to compile C++ code and noticed slow downs when multiple threads of a process were compiling at once. *perf *indicated that most of the CPU time was spent in a spin lock, which was being locked/unlocked from llvm::PassRegistry::getPassInfo(). We read the relevant LLVM code and found out that PassRegistry is a ManagedStatic and is shared among all threads in case of a

On Tue, Apr 23, 2013 at 10:29:32AM +0400, Anton Korobeynikov wrote: > Hello > > There is not support for big endian ARM at all. I guess he need to change the data layout string in ARMTargetMachine::ARMTargetMachine (ARMTargetMachine.cpp) from "e" to "E" to get big endian output? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information

The problems happens because PMTopLevelManager::findAnalysisPassInfo(AnalysisID AID) returns nullptr in PMTopLevelManager::addImmutablePass(ImmutablePass *P). This because PassRegistry::getPassRegistry()->getPassInfo(AID) call in it returns nullptr as well. Should I probably register the pass I want to add with PassRegistry::registerPass(const PassInfo &PI, bool ShouldFree) ? I didn’t do it

Passes all need to be initialized before they are added into a pass manager. Are you calling TargetLibraryInfoWrapperPass::initializePass anywhere? -Chris > On Mar 24, 2016, at 10:41 AM, Lorenzo Laneve via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The problems happens because PMTopLevelManager::findAnalysisPassInfo(AnalysisID AID) returns nullptr in

> I guess he need to change the data layout string in > ARMTargetMachine::ARMTargetMachine (ARMTargetMachine.cpp) > from "e" to "E" to get big endian output? That would be a start, but I'd expect a significant number of bugs where the backend writers have assumed ARM was little-endian (lib/Target/Mips, which *does* support both, has many more endian checks in the

We have root caused the segfault - it was due to a caching layer we have in our code, which is to avoid duplicate compilations. Basically, llvm::JIT::getPointerToFunction() looks up PassRegistry, but as our change introduces a separate PassRegistry for each thread, this means that the thread that calls llvm::JIT::getPointerToFunction() should have appropriate PassRegistry setup. In our setup, some

---------- Forwarded message ---------- From: Qingan Li <ww345ww at gmail.com> Date: 2011/5/30 Subject: To: llvmdev at cs.uiuc.edu Hi, I wrote an analysis pass, myPass, inherited from both ModulePass and ProfileInfo, and this pass requires the CallGraph, i.e., * class myPass : public ModulePass, public ProfileInfo { ...};* * void myPass::getAnalysisUsage(AnalysisUsage &AU) const

I recall having a similar problem while coding my own special-purpose "opt". My guess: try adding the following lines before your pass is inserted into the PassManager: PassRegistry &Registry = *PassRegistry::getPassRegistry(); initializeIPA(Registry); You might require other library initializations. Have a look at the "opt" source code. On 02/12/13 10:36,

Hi, I am running into the same issue with a module pass, that calls LoopInfo.(does not call DominatorTree) I am using RegisterPass, since it is a dynamically loaded module(as per lib/Transforms/Hello) It does seem possible from the discussion, to use LoopInfo inside a ModulePass. I am wondering what the fix to this problem was. Also, the code works in 2.7.(I did not try 2.8) Thanks, Arushi

Those lines of code are in a function that is called before calling the moduleToObjectFile() function > On Mar 24, 2016, at 6:07 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > You may want to try adding this code (copy/pasted from llc.cpp): > > // Initialize targets first, so that --version shows registered targets. > InitializeAllTargets(); >

I actually had an idea about how to fix this in a relatively painless manner. Although given my experience over the past 4 days, it might not be best to call it painless without first trying :) The idea is to make a StaticPassRegistry. RegisterPass<> only touches the StaticPassRegistry, and nothing else touches the StaticPassRegistry. So once you enter main(), StaticPassRegistry can be

The mutex could be made an actual global static instead of a ManagedStatic. This guarantees it would be constructed before main, and live until the end of main. So even in PassRegistry's destructor, which would get call during llvm_shutdown(), it would always have the same mutex. Ideally I'd like to just delete the mutex, as it doesn't seem like anyone is using it in a

Sorry to keep dragging this out on you. Im now getting: Assertion failed: (ResultPass && "getAnalysis*() called on an analysis that was not " "'required' by pass!"), function getAnalysisID But I already have: void getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<DominatorTree>(); } And changed the bottom of my pass too: char Hello::ID =

+cc original authors of these changes. Is PassRegistry intended to be thread-safe? The header file explicitly says that PassRegistry is not thread-safe, but there are mutexes and locking used in the code. This is actually creating a problem, because of a subtle bug involving static initialization order and shutdown. In particular, the RegisterPass<> static template will get invoked

Hi Michael, > When migrating my project to 2.9, I've encountered a strange segfault > where if a ModulePass's getAnalysisUsage adds LoopInfo and > DominatorTree, then llvm::PMTopLevelManager::findAnalysisUsage will > segfault. I suggest you build LLVM with assertions enabled - then you should get a helpful error message rather than a segfault. I think you are not allowed to

I am trying to figure out how to free up some memory that seems to be lost when running valgrind under our internal application. The stack traces I get are: ==19966== 4 bytes in 1 blocks are still reachable in loss record 1 of 12 ==19966== at 0x402569A: operator new(unsigned int) (vg_replace_malloc.c:255) ==19966== by 0x5D9BBE8: void* llvm::object_creator<llvm::PassRegistry>()

Frontends _are_ using PassBuilder, but they need to hook into the default pipeline creation to insert the sanitizer passes. On Tue, Sep 25, 2018 at 12:15 PM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > Hmm... frontends should be using PassBuilder anyway. > And if they are using PassBuilder then they are using PassRegistry.def as > well - all the >

Hi Leonard, Fedor, while it's true that RegisterPass is not applicable for new-pm passes, PassRegistry.def is not the whole story. Passes in PassRegistry are available for the opt tool. The sanitizers are passes that usually get added to the pipeline by the frontend. There, you need to use PassBuilder's callbacks mechanism to hook the sanitizer into the optimizer. Assuming you're