search for: addirpass

Hi, Is there a mechanism in place to use the new pass manager with target-specific passes added (at the moment) via addIRPasses in TargetPassConfig? I did see any code related to that, did I miss something? Is it in plan? -- Krzysztof Parzyszek kparzysz at quicinc.com AI tools development

...er::EmitStartOfAsmFile(), since I'd like to have some processed information available once entering this function. Looking through "Writing an LLVM pass" documentation, it's not clear to me if this is possible. I've also tried putting the pass in different orders (addPreISel, addIRPasses, and etc.). Am I missing something or this is just not possible to do? Any help is appreciated. Thanks, Cheng-Chih -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140930/78e83ad1/attachment.html>

...e you worried that adding it to PMB will increase compile time? > The pass exits very early for any target that doesn't opt-in to doing > scalarisation at the IR level, without even looking at the function. As an alternative, adding Scalarizer and InstCombine passes to SystemZPassConfig::addIRPasses() would probably give me most of the benefit without affecting the PMB. Scalarizer itself would then not test TargetTransformInfo at all, at least in the initial version, and the scalarisation would still logically be done by codegen. Would that be OK? Thanks, Richard

...Mehdi, I meant when I build the LLVM and it will give the following errors: make[2]: Entering directory `/home/alex/new/llvm-obj/tools/llc' llvm[2]: Linking Debug+Asserts executable llc /home/alex/new/llvm-obj/Debug+Asserts/lib/libLLVMCodeGen.a(Passes.o): In function `llvm::TargetPassConfig::addIRPasses()': /home/alex/new/llvm-3.1.src/lib/CodeGen/Passes.cpp:295: undefined reference to `llvm::createMyAliasAnalysisPass()' collect2: ld returned 1 exit status make[2]: *** [/home/alex/new/llvm-obj/Debug+Asserts/bin/llc] Error 1 make[2]: Leaving directory `/home/alex/new/llvm-obj/tools/llc'...

...s 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 addIRPasses(). On Mon, Jun 24, 2013 at 11:20 AM, Antony Yu <swpenim at gmail.com> wrote: > 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...

...ng it to PMB will increase compile time? >> The pass exits very early for any target that doesn't opt-in to doing >> scalarisation at the IR level, without even looking at the function. > > As an alternative, adding Scalarizer and InstCombine passes to > SystemZPassConfig::addIRPasses() would probably give me most of the > benefit without affecting the PMB. Scalarizer itself would then not > test TargetTransformInfo at all, at least in the initial version, > and the scalarisation would still logically be done by codegen. > Would that be OK? I actually prefer that...

...idea is sound. This does mean that running "opt -vectorize foo.bc" would not get the same optimization as running clang with the target you want enabled though. We already have this problem with -loop-reduce though. > LoopStrengthReduction is currently created in TargetPassConfig::addIRPasses (CodeGen/Passes.cpp). Currently the vectorization pass is created in PassManagerBuilder::populateModulePassManager (which is used by opt). Are you suggesting that I move the vectorization pass creation into CodeGen? Or are you saying that TLI will sometimes be available to the pass, as it is now,...

...crease compile time? >>> The pass exits very early for any target that doesn't opt-in to doing >>> scalarisation at the IR level, without even looking at the function. >> >> As an alternative, adding Scalarizer and InstCombine passes to >> SystemZPassConfig::addIRPasses() would probably give me most of the >> benefit without affecting the PMB. Scalarizer itself would then not >> test TargetTransformInfo at all, at least in the initial version, >> and the scalarisation would still logically be done by codegen. >> Would that be OK? > &g...

...>>>> The pass exits very early for any target that doesn't opt-in to doing >>>> scalarisation at the IR level, without even looking at the function. >>> >>> As an alternative, adding Scalarizer and InstCombine passes to >>> SystemZPassConfig::addIRPasses() would probably give me most of the >>> benefit without affecting the PMB. Scalarizer itself would then not >>> test TargetTransformInfo at all, at least in the initial version, >>> and the scalarisation would still logically be done by codegen. >>> Would tha...

...uence 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 addIRPasses(). > > -- > > Thanks, > > Justin Holewinski > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at .uiuc > http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -- View this mes...

MipsOptimizeMathLibCalls.cpp converts: g = sqrt (f); into: r1 = sqrt (f) readonly; if (g is a NaN) r2 = sqrt (f); g = phi (r1, r2) I'd like to do the same on z. Would it be OK to make this pass generic and do the transformation whenever FSQRT isLegalOrCustom for the type? If so, should it stay a separate pass, or should I merge it with something else? Thanks, Richard

Ping. Richard Sandiford <rsandifo at linux.vnet.ibm.com> writes: > MipsOptimizeMathLibCalls.cpp converts: > > g = sqrt (f); > > into: > > r1 = sqrt (f) readonly; > if (g is a NaN) > r2 = sqrt (f); > g = phi (r1, r2) > > I'd like to do the same on z. Would it be OK to make this pass generic > and do the transformation whenever FSQRT

Nadav Rotem <nrotem at apple.com> writes: >> I don't understand the basis for the last statement though. Do you mean >> that you think most cases produce better code if scalarised at the SD stage >> rather than at the IR level? Could you give an example? > > You presented an example that shows that scalarizing vectors allow > further optimizations. But I

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:

Hi all, I create a folder containing my new alias analysis pass in the lib/Analysis folder of the source tree. I mimic the way IPA did to create a LLVMipa.a library. That is, I write a Makefile to create my library and I change the Makefile correspondingly in the Analysis folder. However, when I want to use my new alias analysis in the Codegen. The compiler will complain "undefined

Hi Richard, Thanks for working on this. Comments below. > I don't understand the basis for the last statement though. Do you mean > that you think most cases produce better code if scalarised at the SD stage > rather than at the IR level? Could you give an example? You presented an example that shows that scalarizing vectors allow further optimizations. But I don’t think that

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{

...a compile time will be significant, and we shouldn't prematurely optimize (although we should check for any significant impact). The intrinsics should be scalarized on all targets without support (by lib/CodeGen/ScalarizeMaskedMemIntrin.cpp which is scheduled by default in TargetPassConfig::addIRPasses). -Hal > > Thanks, > Hideki > > -----Original Message----- > From: aemerson at apple.com [mailto:aemerson at apple.com] > Sent: Friday, January 05, 2018 3:38 PM > To: Saito, Hideki <hideki.saito at intel.com> > Cc: llvm-dev at lists.llvm.org; Hal Finkel <hf...

...xtra compile time will be significant, and we shouldn't prematurely optimize (although we should check for any significant impact). The intrinsics should be scalarized on all targets without support (by lib/CodeGen/ScalarizeMaskedMemIntrin.cpp which is scheduled by default in TargetPassConfig::addIRPasses). -Hal > > Thanks, > Hideki > > -----Original Message----- > From: aemerson at apple.com [mailto:aemerson at apple.com] > Sent: Friday, January 05, 2018 3:38 PM > To: Saito, Hideki <hideki.saito at intel.com> > Cc: llvm-dev at lists.llvm.org; Hal Finkel <hf...

Amara, >I support this direction Thanks for the support. >but are there actually any real world workloads where gather/scatter scalarisation would be worth it, on any micro-architecture? If we don’t have examples and the compile time cost is non-negligible then I think we’d still like to keep the early >bailouts in some form.’ It's not like I have specific application code in