similar to: [LLVMdev] About writing a modulePass in addPreEmitPass() for NVPTX

Are you sure you are initializing your pass properly? Can you show a stripped down version of your pass? On Fri, Jun 21, 2013 at 7:27 AM, Anthony Yu <swpenim at gmail.com> wrote: > Hello, > > I want to write a modulePass in addPreEmitPass() for NVPTX, but I > encounter an assertion failed when executing clang. > > Here is my error message. > ==== > Pass 'NVPTX

I write my pass in a mix way of NVPTXAllocaHoisting, NVPTXSplitBBatBar and transforms/Hello. The following is part of the codes: in NVPTXTargetMachine.cpp bool NVPTXPassConfig::addPreEmitPass() { addPass(createTest()); return false; } in NVPTXTest.h namespace llvm{

I try to use INITIALIZE_PASS instead of RegisterPass<> to register my pass, though I don't understand what's their difference and how it works because its documents doesn't exist. But it still doesn't work. Parts of my codes is as follows: in NVPTXTest.h namespace llvm { void initializeNVPTXTestPass(PassRegistry &r); class NVPTXTest : public ModulePass { public:

Sorry for the delay. Yeah, that error message is a bit confusing. What's happening is that your pass sequence is invalid. Once the IR has been lowered to machine code, its too late to run LLVM IR passes (ModulePass, FunctionPass, CallGraphSCCPass, etc.). At that point, you need to run a Machine*Pass, e.g. MachineFunctionPass. If you need to run an IR level pass, you need to use

Oops! No need of Call Graph! In fact, what I want to do is to find which function is the kernel function and which function is called by that kernel. Since OpenCL will make all functions called by kernels inline, I can use function attribute: Noinline to distinguish them. Sorry for bothering you. Antony Yu -- View this message in context:

So that's how it is !! Thanks! Hmm, in fact, I want to get Call Graph information in machine code stage, is there any way to get this? I try CallGraph &g= getAnalysis<CallGraph>, but it prints the same error and doesn't work as expected. Antony Yu Justin Holewinski-2 wrote > Sorry for the delay. Yeah, that error message is a bit confusing. What's > happening is

You shouldn't rely on that, its an implementation detail. Instead, you can trace back to the original Function object and check for kernel metadata. See http://llvm.org/docs/NVPTXUsage.html#marking-functions-as-kernels On Tue, Jun 25, 2013 at 11:09 AM, Antony Yu <swpenim at gmail.com> wrote: > Oops! No need of Call Graph! > In fact, what I want to do is to find which function

Hi, all: I wanted to use a FunctionPass (e.g. *MemoryDependenceAnalysis*) in a ModulePass, and then I used the method "getAnalysis<* MemoryDependenceAnalysis*>(llvm::Function *)" described at http://llvm.org/docs/WritingAnLLVMPass.html#ModulePass to get the FunctionPass. But , it still crashed when I invoked this pass in tool 'opt'. However, if I change my pass to

---------- 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

Hi, We are getting ready to implement several heuristics for correctly using LEAs to avoid stalls in the address generator on Atom. Our plan is to: 1. Disabling LEA generation on Atom in X86ISelDAGToDAG:: SelectLEAAddr() for all but a few pseudo-instructions 2. Identify loads and stores in a X86PassConfig::addPreEmitPass() pass and examine several preceding instructions to

for ARM constant islands and Mips constant islands, the constant islands pass is registered as an addPreEmitPass. for mips at least, it ends of up getting called twice by the pass manager. why is that?

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 &&

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

Thank you so much. That helped alot. Fami On Wed, Nov 4, 2015 at 9:40 AM, John Criswell <jtcriswel at gmail.com> wrote: > On 11/3/15 7:54 PM, fateme Hoseini wrote: > > Dear John, > Thank you so much for your help. I looked at those documents. Could you > kindly answer the following questions: > > Does it mean that I have to make my own backend target in order to write

Hi, So, I run my pass in X86 target with llc command and it printed out "hello****". Now I am trying to do the same pass for ARM target. So I did exactly what I did for X86 as mentioned in my previous posts. When I run the following command: llc -march=arm test.ll -o test nothing prints out. I did the same for MIPS target too and I got no result. Can anyone tell me what I'm doing

So we come back to my earlier comment: can you produce a one-file, < 100 lines that reproduce the issue? -- Mehdi > On Mar 24, 2016, at 10:16 AM, Lorenzo Laneve <lore97drk at icloud.com> wrote: > > 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

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. What's odd is that if I rearrange this (add required for DominatorTree before LoopInfo), it does not segfault. I realize that LoopInfo requires and preserves DominatorTree, but this

Thanks for the response. I do have assertions enabled, and none of them are getting hit. I did do a search of the mailing list for the past year (approximately) before writing my email, and what I found was that you should be allowed to use LoopInfo and other analysis function passes from a module pass, with the only difference being that getAnalysis is passed the function. The example code I