search for: addextension

...> patch, it is totally fine. =D > 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). ? --kcc > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -------------- next part -------------- An HTML attachment was...

...;> 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? OK, I withdraw my suggestion :) - Devang

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

...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? > > OK, I withdraw my suggestion :) > Does anyone else have comments to the original patch (attached)? Thanks, --kcc > > - > Devang > > --------...

...ly 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? >> >> OK, I withdraw my suggestion :) >> > > Does anyone else have comments to the original patch (attached)? > Thanks, > I already...

...lib/Transforms/IPO/PassManagerBuilder.cpp===================================================================--- lib/Transforms/IPO/PassManagerBuilder.cpp   (revision 144800)+++ lib/Transforms/IPO/PassManagerBuilder.cpp   (working copy)@@ -101,6 +101,7 @@     MPM.add(Inliner);     Inliner = 0;   }+ addExtensionsToPM(EP_EnabledOnOptLevel0, MPM);   return; } Index: tools/clang/lib/CodeGen/BackendUtil.cpp===================================================================--- tools/clang/lib/CodeGen/BackendUtil.cpp     (revision 144800)+++ tools/clang/lib/CodeGen/BackendUtil.cpp     (working copy)@@ -150,6 +15...

...ded to LLVM, then it's not clear to me how to return the > stack size information to the host C++ program either. There currently aren't any hooks for this, but it probably wouldn't be hard to implement, if you're interested in contributing upstream.  (See PassManagerBuilder::addExtension for IR optimization passes.) -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

...nted twice (which causes run-time crash). This happens only at -O0; at -O1 we get the correct order of events for some reason (foo gets inlined, then foo and bar are instrumented). The code looks like this: tools/clang/lib/CodeGen/BackendUtil.cpp if (LangOpts.AddressSanitizer) { PMBuilder.addExtension(PassManagerBuilder::EP_OptimizerLast, addAddressSanitizerPass); PMBuilder.addExtension(PassManagerBuilder::EP_EnabledOnOptLevel0, addAddressSanitizerPass); } lib/Transforms/IPO/PassManagerBuilder.cpp void PassManagerBuilder::popu...

Hi all, I'm trying to get the amount of stack memory used by the functions I am JIT compiling with LLVM. I have a host C++ program, and I want to be able to access the stack size from the host C++ program. I see in PrologEpilogInserter.cpp that the computed stack size is read from the MachineFunction corresponding to a Function, in order to issue a warning if the stack size is too large.

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

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 to llvm-commits and cfe-commits. However, looking at the Clang side of the patch, it is totally fine. =D --------------

...TargetLibraryInfoImpl tlii(Triple(module->getTargetTriple())); PMBuilder->LibraryInfo = &tlii; if (is_debug) { PMBuilder->Inliner = createAlwaysInlinerLegacyPass(false); } else { target_machine->adjustPassManager(*PMBuilder); PMBuilder->addExtension(PassManagerBuilder::EP_EarlyAsPossible, addDiscriminatorsPass); PMBuilder->Inliner = createFunctionInliningPass(PMBuilder->OptLevel, PMBuilder->SizeLevel, false); } addCoroutinePassesToExtensionPoints(*PMBuilder); // Set up the per-function pass manager. legacy::F...

On Thu, Jun 4, 2015 at 5:33 PM, Reid Kleckner <rnk at google.com> wrote: > On Thu, Jun 4, 2015 at 5:17 PM, Teresa Johnson <tejohnson at google.com> wrote: >> >> Agreed. Although I assume you mean invoke the new pass under a >> ThinLTO-only option so that avail extern are not dropped in the >> compile pass before the LTO link? > > > No, this pass

On Thu, Jun 4, 2015 at 3:58 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > Personally, I think the right approach is to add a bool to > createGlobalDCEPass defaulting to true named something like > IsAfterInlining. In most standard pass pipelines, GlobalDCE runs after > inlining for obvious reasons, so the default makes sense. The special case > is

...::CreatePasses() { PMBuilder.DisableUnitAtATime = !CodeGenOpts.UnitAtATime; PMBuilder.DisableUnrollLoops = !CodeGenOpts.UnrollLoops; PMBuilder.MergeFunctions = CodeGenOpts.MergeFunctions; + PMBuilder.LTO = CodeGenOpts.LTO; PMBuilder.RerollLoops = CodeGenOpts.RerollLoops; PMBuilder.addExtension(PassManagerBuilder::EP_EarlyAsPossible, Index: lib/Driver/Tools.cpp =================================================================== --- lib/Driver/Tools.cpp (revision 237590) +++ lib/Driver/Tools.cpp (working copy) @@ -2676,6 +2676,10 @@ void Clang::ConstructJob(Compilation &C, const Job...