similar to: [LLVMdev] please advise on PassManager

Hi LLVMdev, llvm::PassManagerBuilder allows to customize the default pass sequenceby registering passes at specific extension points.However all of theextensions if the -O0 flag is added to the command line; as thecomment says, "If all optimizations are disabled, just run thealways-inline pass."This doesn't play well with _instrumentation_passes which should not be disabled

Hi, Sean: I'm sorry I lie. I didn't mean to lie. I did try to avoid making a *BIG* change to the IPO pass-ordering for now. However, when I make a minor change to populateLTOPassManager() by separating module-pass and non-module-passes, I saw quite a few performance difference, most of them are degradations. Attacking these degradations one by one in a piecemeal manner is wasting

Here is some timing information from running the Zig standard library tests: $ ./zig test ../std/index.zig --enable-timing-info Name Start End Duration Percent Initialize 0.0000 0.0010 0.0010 0.0001 Semantic Analysis 0.0010 0.9968 0.9958 0.1192 Code Generation 0.9968 1.4000 0.4032

Talked to Eric Fri and he suggested that this might be the first of several places where we want behavior of LTO compiles to diverge from normal -O2 compiles. So for now I have implemented this such that we pass down -flto to the -cc1 job, and that gets propagated as a code gen option and into the PassManagerBuilder. I have left the current logic translating -flto to the -emit-llvm-bc option,

Hi, This is Ariel from the Rust team again. I am having another pass ordering issue. Looking at the pass manager at https://github.com/llvm-mirror/llvm/blob/7034870f30320d6fbc74effff539d946018cd00a/lib/Transforms/IPO/PassManagerBuilder.cpp (the early SimplifyCfg now doesn't sink stores anymore! I can't wait until I can get to use that in rustc!) I find that the loop optimization group

Hi, If we add multiple loop passes to the pass manager in PassManagerBuilder.cpp consecutively without any func/module pass in between, I used to think they would belong to the same loop pass manager. But it does not seem to be the case. For example for this code snippet PM.add(createIndVarSimplifyPass()); // Canonicalize indvars MPM.add(createLoopIdiomPass()); //

On 04/17/2013 09:04 PM, Sebastian Pop wrote: > Tobias Grosser wrote: >> As said before, we could probably add it in between those two passes: >> >> MPM.add(createReassociatePass()); // Reassociate expressions >> + addExtensionsToPM(EP_LoopOptimizerStart, MPM); >> MPM.add(createLoopRotatePass()); // Rotate Loop > > As this is in the middle of other

On Tue, Nov 29, 2011 at 4:31 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Tue, Nov 29, 2011 at 8:56 AM, Alexander Potapenko <glider at google.com>wrote: > >> PS. Should we move the discussion to cfe-commits or it's ok to >> continue the review process here? >> > > For future reference, please send patches which touch both LLVM and Clang

On Nov 29, 2011, at 11:26 PM, Alexander Potapenko wrote: >> >> Alex, >> Now, the patch is actually a bit confusing to me. >> EP_AlwaysEnabled should mean "works with O0 after inliner and with >= O1 >> somewhere late", but it doesn't look like it works this way (otherwise, you >> wouldn't need to call PMBuilder.addExtension twice). >>

Tobias Grosser wrote: > As said before, we could probably add it in between those two passes: > > MPM.add(createReassociatePass()); // Reassociate expressions > + addExtensionsToPM(EP_LoopOptimizerStart, MPM); > MPM.add(createLoopRotatePass()); // Rotate Loop As this is in the middle of other LNO passes, can you please rename s/EP_LoopOptimizerStart/EP_Polly_LNO/ or

> > Alex, > Now, the patch is actually a bit confusing to me. > EP_AlwaysEnabled should mean "works with O0 after inliner and with >= O1 > somewhere late", but it doesn't look like it works this way (otherwise, you > wouldn't need to call PMBuilder.addExtension twice). > ? This was actually my question to Devang. Any other suggestions for the EP name?

+cfe-commits (as the patch touches both llvm and clang) On Wed, Nov 30, 2011 at 9:33 AM, Devang Patel <dpatel at apple.com> wrote: > > On Nov 29, 2011, at 11:26 PM, Alexander Potapenko wrote: > > >> > >> Alex, > >> Now, the patch is actually a bit confusing to me. > >> EP_AlwaysEnabled should mean "works with O0 after inliner and with >=

On Wed, Nov 30, 2011 at 11:04 AM, Kostya Serebryany <kcc at google.com> wrote: > +cfe-commits (as the patch touches both llvm and clang) > > On Wed, Nov 30, 2011 at 9:33 AM, Devang Patel <dpatel at apple.com> wrote: > >> >> On Nov 29, 2011, at 11:26 PM, Alexander Potapenko wrote: >> >> >> >> >> Alex, >> >> Now, the

On 04/17/2013 08:37 PM, Sebastian Pop wrote: > Tobias Grosser wrote: >> On 04/17/2013 05:53 PM, Sebastian Pop wrote: >>> Hi, >>> >>> polly is run very early and schedules the following passes before it runs: >>> >>> /// @brief Schedule a set of canonicalization passes to prepare for Polly >>> /// >>> /// The set of

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of nlamee at cs.mcgill.ca > Subject: [LLVMdev] Execution Engine: CodeGenOpt level > How can I dynamically change the code generation optimization level (e.g., > None) of a JIT in other to recompile a function with a new optimization > level (e.g., Default)? We set the optimization level with a

> >> + EP_EnabledOnOptLevel0 > > I'd rename this as EP_AlwaysEnabled > Renamed, see the attachment. But note that one needs to add his pass at two extension points: at O0 and wherever else he wanted to add it. Won't such a name confuse the user? E.g. he may think that just adding a pass as "EP_AlwaysEnabled" should be enough to have it at any optimization

Andy and I briefly discussed this the other day, we have not yet got chance to list a detailed pass order for the pre- and post- IPO scalar optimizations. This is wish-list in our mind: pre-IPO: based on the ordering he propose, get rid of the inlining (or just inline tiny func), get rid of all loop xforms... post-IPO: get rid of inlining, or maybe we still need it, only

Tobias, I've attached an updated patch. It contains a few bug fixes and many (refactoring and coding-convention) changes inspired by your comments. I'm currently trying to fix the bug responsible for causing a compile failure when compiling test-suite/MultiSource/Applications/obsequi/toggle_move.c; after the pass begins to fuse instructions in a basic block in this file, the aliasing

Hi Eli, I have tried that: static void registerMyPass(const PassManagerBuilder &, llvm::legacy::PassManagerBase &PM) { PM.add(new MyPass()); } static RegisterStandardPasses RegisterMyPass(PassManagerBuilder::EP_OptimizerLast, registerMyPass); It still couldn't find my pass. Regards, Soham Sinha PhD Student,

Here is an update about moving Polly later. 1. Why does Polly generate incorrect code when we move Polly immediately after the loop rotating pass? It is mainly caused by a wrong polly merge block. When Polly detects a valid loop for Polyhedral transformations, it usually introduces a new basic block "polly.merge_new_and_old" after the original loop exit block. This new basic block