<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 1, 2017 at 5:48 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div class="gmail-h5"><div dir="ltr">On Thu, Jun 1, 2017 at 11:20 AM Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 1, 2017 at 4:39 AM, Chandler Carruth via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Author: chandlerc<br>
Date: Thu Jun 1 06:39:39 2017<br>
New Revision: 304407<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=304407&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-<wbr>project?rev=304407&view=rev</a><br>
Log:<br>
[PM/ThinLTO] Port the ThinLTO pipeline (both components) to the new PM.<br>
<br>
Based on the original patch by Davide, but I've adjusted the API exposed<br>
to just be different entry points rather than exposing more state<br>
parameters. I've factored all the common logic out so that we don't have<br>
any duplicate pipelines, we just stitch them together in different ways.<br>
I think this makes the build easier to reason about and understand.<br>
<br>
This adds a direct method for getting the module simplification pipeline<br>
as well as a method to get the optimization pipeline. While not my<br>
express goal, this seems nice and gives a good place comment about the<br>
restrictions that are imposed on them.<br>
<br>
I did make some minor changes to the way the pipelines are structured<br>
here, but hopefully not ones that are significant or controversial:<br>
<br>
1) I sunk the PGO indirect call promotion to only be run when we have<br>
PGO enabled (or as part of the special ThinLTO pipeline).<br>
<br>
2) I made the extra GlobalOpt run in ThinLTO just happen all the time<br>
and at a slightly more powerful place (before we remove available<br>
externaly functions). This seems like general goodness and not a big<br>
compile time sink, so it didn't make sense to *only* use it in<br>
ThinLTO. Fewer differences in the pipeline makes everything simpler<br>
IMO.<br>
<br>
3) I hoisted the ThinLTO stop point pre-link above the the RPO function<br>
attr inference. The RPO inference won't infer anything terribly<br>
meaningful pre-link (recursiveness?) so it didn't make a lot of<br>
sense. But if the placement of RPO inference starts to matter, we<br>
should move it to the canonicalization phase anyways which seems like<br>
a better place for it (and there is a FIXME to this effect!). But<br>
that seemed a bridge too far for this patch.<br>
<br>
If we ever need to parameterize these pipelines more heavily, we can<br>
always sink the logic to helper functions with parameters to keep those<br>
parameters out of the public API. But the changes above seemed minor<br>
that we could possible get away without the parameters entirely.<br>
<br>
I added support for parsing 'thinlto' and 'thinlto-pre-link' names in<br>
pass pipelines to make it easy to test these routines and play with them<br>
in larger pipelines. I also added a really basic manifest of passes test<br>
that will show exactly how the pipelines behave and work as well as<br>
making updates to them clear.<br>
<br>
Lastly, this factoring does introduce a nesting layer of module pass<br>
managers in the default pipeline. I don't think this is a big deal and<br>
the flexibility of decoupling the pipelines seems easily worth it.<br>
<br>
Differential Revision: <a href="https://reviews.llvm.org/D33540" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D33540</a><br>
<br>
Added:<br>
llvm/trunk/test/Other/new-pm-<wbr>thinlto-defaults.ll<br>
- copied, changed from r304404, llvm/trunk/test/Other/new-pm-<wbr>defaults.ll<br>
llvm/trunk/test/ThinLTO/X86/<wbr>newpm-basic.ll<br>
- copied, changed from r304404, llvm/trunk/test/ThinLTO/X86/<wbr>error-newpm.ll<br>
Removed:<br>
llvm/trunk/test/ThinLTO/X86/<wbr>error-newpm.ll<br>
Modified:<br>
llvm/trunk/include/llvm/<wbr>Passes/PassBuilder.h<br>
llvm/trunk/lib/LTO/LTOBackend.<wbr>cpp<br>
llvm/trunk/lib/Passes/<wbr>PassBuilder.cpp<br>
llvm/trunk/test/Other/new-pm-<wbr>defaults.ll<br>
<br>
Modified: llvm/trunk/include/llvm/<wbr>Passes/PassBuilder.h<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Passes/PassBuilder.h?rev=304407&r1=304406&r2=304407&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-<wbr>project/llvm/trunk/include/<wbr>llvm/Passes/PassBuilder.h?rev=<wbr>304407&r1=304406&r2=304407&<wbr>view=diff</a><br>
==============================<wbr>==============================<wbr>==================<br>
--- llvm/trunk/include/llvm/<wbr>Passes/PassBuilder.h (original)<br>
+++ llvm/trunk/include/llvm/<wbr>Passes/PassBuilder.h Thu Jun 1 06:39:39 2017<br>
@@ -192,6 +192,39 @@ public:<br>
<wbr>buildFunctionSimplificationPip<wbr>eline(OptimizationLevel Level,<br>
bool DebugLogging = false);<br>
<br>
+ /// Construct the core LLVM module canonicalization and simplification<br>
+ /// pipeline.<br>
+ ///<br>
+ /// This pipeline focuses on canonicalizing and simplifying the entire module<br>
+ /// of IR. Much like the function simplification pipeline above, it is<br>
+ /// suitable to run repeatedly over the IR and is not expected to destroy<br>
+ /// important information. It does, however, perform inlining and other<br>
+ /// heuristic based simplifications that are not strictly reversible.<br>
+ ///<br>
+ /// Note that \p Level cannot be `O0` here. The pipelines produced are<br>
+ /// only intended for use when attempting to optimize code. If frontends<br>
+ /// require some transformations for semantic reasons, they should explicitly<br>
+ /// build them.<br>
+ ModulePassManager<br>
+ buildModuleSimplificationPipel<wbr>ine(OptimizationLevel Level,<br>
+ bool DebugLogging = false);<br>
+<br>
+ /// Construct the core LLVM module optimization pipeline.<br>
+ ///<br>
+ /// This pipeline focuses on optimizing the execution speed of the IR. It<br>
+ /// uses cost modeling and thresholds to balance code growth against runtime<br>
+ /// improvements. It includes vectorization and other information destroying<br>
+ /// transformations. It also cannot generally be run repeatedly on a module<br>
+ /// without potentially seriously regressing either runtime performance of<br>
+ /// the code or serious code size growth.<br>
+ ///<br>
+ /// Note that \p Level cannot be `O0` here. The pipelines produced are<br>
+ /// only intended for use when attempting to optimize code. If frontends<br>
+ /// require some transformations for semantic reasons, they should explicitly<br>
+ /// build them.<br>
+ ModulePassManager buildModuleOptimizationPipelin<wbr>e(OptimizationLevel Level,<br>
+ bool DebugLogging = false);<br>
+<br>
/// Build a per-module default optimization pipeline.<br>
///<br>
/// This provides a good default optimization pipeline for per-module<br>
@@ -206,6 +239,36 @@ public:<br>
ModulePassManager buildPerModuleDefaultPipeline(<wbr>OptimizationLevel Level,<br>
bool DebugLogging = false);<br>
<br>
+ /// Build a pre-link, ThinLTO-targeting default optimization pipeline to<br>
+ /// a pass manager.<br>
+ ///<br>
+ /// This adds the pre-link optimizations tuned to prepare a module for<br>
+ /// a ThinLTO run. It works to minimize the IR which needs to be analyzed<br>
+ /// without making irreversible decisions which could be made better during<br>
+ /// the LTO run.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I think this name `pre-link` is probably as good as we can come up with for the moment, but it might be good just for clarity and explicitness to say something like "For example, this is the optimization pipeline that the per-TU clang invocation would run with -flto=thin".</div></div></div></div></blockquote><div><br></div></div></div><div>Can you think of a way to explain this without referencing Clang? It feels bad to explain LLVM stuff in terms of Clang stuff. (I tried a few things and they all ended up completely redundant or completely confusing...)</div></div></div></blockquote><div><br></div><div>I agree with the sentiment in general, but prefaced with `For example` I think it is reasonable. I think this is especially true since some (most?) of our documentation widely disseminating understanding of ThinLTO does describe it from the point of view of a general C/C++ build workflow (e.g. <a href="https://www.youtube.com/watch?v=9OIEZAj243g">https://www.youtube.com/watch?v=9OIEZAj243g</a>). That was good choice I think because C/C++ build workflows will be something that people hacking on/using LLVM will be familiar with regardless of what their intended frontend is.</div><div><br></div><div>In fact, it may be useful to explicitly call out in the docs how our new terminology correlates with the terminology used at e.g. <a href="https://youtu.be/9OIEZAj243g?t=15m52s">https://youtu.be/9OIEZAj243g?t=15m52s</a></div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
+ ///<br>
+ /// Note that \p Level cannot be `O0` here. The pipelines produced are<br>
+ /// only intended for use when attempting to optimize code. If frontends<br>
+ /// require some transformations for semantic reasons, they should explicitly<br>
+ /// build them.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
+ ModulePassManager<br>
+ buildThinLTOPreLinkDefaultPipe<wbr>line(OptimizationLevel Level,<br>
+ bool DebugLogging = false);<br>
+<br>
+ /// Build an ThinLTO default optimization pipeline to a pass manager.<br>
+ ///<br>
+ /// This provides a good default optimization pipeline for link-time<br>
+ /// optimization and code generation. It is particularly tuned to fit well<br>
+ /// when IR coming into the LTO phase was first run through \c<br>
+ /// addPreLinkLTODefaultPipeline, and the two coordinate closely.<br>
+ ///<br>
+ /// Note that \p Level cannot be `O0` here. The pipelines produced are<br>
+ /// only intended for use when attempting to optimize code. If frontends<br>
+ /// require some transformations for semantic reasons, they should explicitly<br>
+ /// build them.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Quick question to verify my understanding: with the current design for coroutines, when optimizing, we would actually prefer to do the semantically necessary coroutine lowering while running one of these pipelines that you have marked as "If frontends require some transformations for semantic reasons, they should explicitly build them", essentially being an annoying exception to that (i.e. the frontend would *not* manually run the coroutine lowering passes separately first in that case).</div><div><br></div><div>I realize this may be a can of worms that hasn't been fully figured out now, so I'm totally fine with a "that's still in the air" type answer. E.g. we presumably want to do coroutine lowering in the very last inlining run that we do (i.e. post-thin-link), so we would need to always assume that our input bitcode hasn't necessarily had the coroutine lowering run on it, so the post-thin-link optimization pipeline would always need to run coroutine lowering?<br></div></div></div></div></blockquote><div><br></div></span><div>I mean, I think this is still a bit up in the air, but I have a theory about how this should eventually end up working.</div><div><br></div><div>I think we can provide extension points that are reasonably used to inject semantically significant passes into the pipeline. Philip has a patch that is coming along nicely here. I'm hoping it will address the Sanitizers' use case off the bat, and that we can craft any other extension points necessary for semantically significant passes.</div><div><br></div><div>That said, part of the solution for coroutines may end up being adjusting how the lowering works to relax some of the requirements. But I think it is totally fine to live with some uncertainty and "this isn't supposed to work that way"-ness while they're still very experimental and we're still figuring the best process out.</div><div><div class="gmail-h5"><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div>-- Sean Silva</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
+ ModulePassManager buildThinLTODefaultPipeline(<wbr>OptimizationLevel Level,<br>
+ bool DebugLogging = false);<br>
+<br>
/// Build a pre-link, LTO-targeting default optimization pipeline to a pass<br>
/// manager.<br>
///<br>
<br>
Modified: llvm/trunk/lib/LTO/LTOBackend.<wbr>cpp<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/LTO/LTOBackend.cpp?rev=304407&r1=304406&r2=304407&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-<wbr>project/llvm/trunk/lib/LTO/<wbr>LTOBackend.cpp?rev=304407&r1=<wbr>304406&r2=304407&view=diff</a><br>
==============================<wbr>==============================<wbr>==================<br>
--- llvm/trunk/lib/LTO/LTOBackend.<wbr>cpp (original)<br>
+++ llvm/trunk/lib/LTO/LTOBackend.<wbr>cpp Thu Jun 1 06:39:39 2017<br>
@@ -136,7 +136,8 @@ createTargetMachine(Config &Conf, const<br>
Conf.CodeModel, Conf.CGOptLevel));<br>
}<br>
<br>
-static void runNewPMPasses(Module &Mod, TargetMachine *TM, unsigned OptLevel) {<br>
+static void runNewPMPasses(Module &Mod, TargetMachine *TM, unsigned OptLevel,<br>
+ bool IsThinLTO) {<br>
PassBuilder PB(TM);<br>
AAManager AA;<br>
<br>
@@ -180,7 +181,10 @@ static void runNewPMPasses(Module &Mod,<br>
break;<br>
}<br>
<br>
- MPM = PB.buildLTODefaultPipeline(OL, false /* DebugLogging */);<br>
+ if (IsThinLTO)<br>
+ MPM = PB.<wbr>buildThinLTODefaultPipeline(<wbr>OL, false /* DebugLogging */);<br>
+ else<br>
+ MPM = PB.buildLTODefaultPipeline(OL, false /* DebugLogging */);<br>
MPM.run(Mod, MAM);<br>
<br>
// FIXME (davide): verify the output.<br>
@@ -258,17 +262,12 @@ static void runOldPMPasses(Config &Conf,<br>
bool opt(Config &Conf, TargetMachine *TM, unsigned Task, Module &Mod,<br>
bool IsThinLTO, ModuleSummaryIndex *ExportSummary,<br>
const ModuleSummaryIndex *ImportSummary) {<br>
- // There's still no ThinLTO pipeline hooked up in the new pass manager,<br>
- // once there is one, we can just remove this.<br>
- if (LTOUseNewPM && IsThinLTO)<br>
- report_fatal_error("ThinLTO not supported with the new PM yet!");<br>
-<br>
// FIXME: Plumb the combined index into the new pass manager.<br>
if (!Conf.OptPipeline.empty())<br>
runNewPMCustomPasses(Mod, TM, Conf.OptPipeline, Conf.AAPipeline,<br>
Conf.DisableVerify);<br>
else if (LTOUseNewPM)<br>
- runNewPMPasses(Mod, TM, Conf.OptLevel);<br>
+ runNewPMPasses(Mod, TM, Conf.OptLevel, IsThinLTO);<br>
else<br>
runOldPMPasses(Conf, Mod, TM, IsThinLTO, ExportSummary, ImportSummary);<br>
return !Conf.PostOptModuleHook || Conf.PostOptModuleHook(Task, Mod);<br>
<br>
Modified: llvm/trunk/lib/Passes/<wbr>PassBuilder.cpp<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Passes/PassBuilder.cpp?rev=304407&r1=304406&r2=304407&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-<wbr>project/llvm/trunk/lib/Passes/<wbr>PassBuilder.cpp?rev=304407&r1=<wbr>304406&r2=304407&view=diff</a><br>
==============================<wbr>==============================<wbr>==================<br>
--- llvm/trunk/lib/Passes/<wbr>PassBuilder.cpp (original)<br>
+++ llvm/trunk/lib/Passes/<wbr>PassBuilder.cpp Thu Jun 1 06:39:39 2017<br>
@@ -164,7 +164,8 @@ static cl::opt<bool> EnableGVNHoist(<br>
"enable-npm-gvn-hoist", cl::init(false), cl::Hidden,<br>
cl::desc("Enable the GVN hoisting pass for the new PM (default = off)"));<br>
<br>
-static Regex DefaultAliasRegex("^(default|<wbr>lto-pre-link|lto)<(O[0123sz])><wbr>$");<br>
+static Regex DefaultAliasRegex(<br>
+ "^(default|thinlto-pre-link|<wbr>thinlto|lto-pre-link|lto)<(O[<wbr>0123sz])>$");<br>
<br>
static bool isOptimizingForSize(<wbr>PassBuilder::OptimizationLevel Level) {<br>
switch (Level) {<br>
@@ -345,6 +346,9 @@ PassBuilder::<wbr>buildFunctionSimplification<br>
LPM2.addPass(<wbr>IndVarSimplifyPass());<br>
LPM2.addPass(<wbr>LoopIdiomRecognizePass());<br>
LPM2.addPass(<wbr>LoopDeletionPass());<br>
+ // FIXME: The old pass manager has a hack to disable loop unrolling during<br>
+ // ThinLTO when using sample PGO. Need to either fix it or port some<br>
+ // workaround.<br>
LPM2.addPass(LoopUnrollPass::<wbr>createFull(Level));<br>
<br>
// We provide the opt remark emitter pass for LICM to use. We only need to do<br>
@@ -454,14 +458,10 @@ static void addPGOInstrPasses(ModulePass<br>
}<br>
<br>
ModulePassManager<br>
-PassBuilder::<wbr>buildPerModuleDefaultPipeline(<wbr>OptimizationLevel Level,<br>
- bool DebugLogging) {<br>
- assert(Level != O0 && "Must request optimizations for the default pipeline!");<br>
+PassBuilder::<wbr>buildModuleSimplificationPipel<wbr>ine(OptimizationLevel Level,<br>
+ bool DebugLogging) {<br>
ModulePassManager MPM(DebugLogging);<br>
<br>
- // Force any function attributes we want the rest of the pipeline te observe.<br>
- MPM.addPass(<wbr>ForceFunctionAttrsPass());<br>
-<br>
// Do basic inference of function attributes from known properties of system<br>
// libraries and other oracles.<br>
MPM.addPass(<wbr>InferFunctionAttrsPass());<br>
@@ -504,16 +504,16 @@ PassBuilder::<wbr>buildPerModuleDefaultPipeli<br>
GlobalCleanupPM.addPass(<wbr>SimplifyCFGPass());<br>
MPM.addPass(<wbr>createModuleToFunctionPassAdap<wbr>tor(std::move(GlobalCleanupPM)<wbr>));<br>
<br>
- // Add all the requested passes for PGO Instrumentation, if requested.<br>
+ // Add all the requested passes for PGO, if requested.<br>
if (PGOOpt) {<br>
assert(PGOOpt->RunProfileGen || PGOOpt->SamplePGO ||<br>
!PGOOpt->ProfileUseFile.empty(<wbr>));<br>
addPGOInstrPasses(MPM, DebugLogging, Level, PGOOpt->RunProfileGen,<br>
PGOOpt->ProfileGenFile, PGOOpt->ProfileUseFile);<br>
- }<br>
<br>
- // Indirect call promotion that promotes intra-module targes only.<br>
- MPM.addPass(<wbr>PGOIndirectCallPromotion(<wbr>false, PGOOpt && PGOOpt->SamplePGO));<br>
+ // Indirect call promotion that promotes intra-module targes only.<br>
+ MPM.addPass(<wbr>PGOIndirectCallPromotion(<wbr>false, PGOOpt && PGOOpt->SamplePGO));<br>
+ }<br>
<br>
// Require the GlobalsAA analysis for the module so we can query it within<br>
// the CGSCC pipeline.<br>
@@ -562,17 +562,30 @@ PassBuilder::<wbr>buildPerModuleDefaultPipeli<br>
<wbr>createModuleToPostOrderCGSCCPa<wbr>ssAdaptor(<wbr>createDevirtSCCRepeatedPass(<br>
std::move(MainCGPipeline), MaxDevirtIterations, DebugLogging)));<br>
<br>
- // This ends the canonicalization and simplification phase of the pipeline.<br>
- // At this point, we expect to have canonical and simple IR which we begin<br>
- // *optimizing* for efficient execution going forward.<br>
+ return MPM;<br>
+}<br>
+<br>
+ModulePassManager<br>
+PassBuilder::<wbr>buildModuleOptimizationPipelin<wbr>e(OptimizationLevel Level,<br>
+ bool DebugLogging) {<br>
+ ModulePassManager MPM(DebugLogging);<br>
+<br>
+ // Optimize globals now that the module is fully simplified.<br>
+ MPM.addPass(GlobalOptPass());<br>
<br>
// Run partial inlining pass to partially inline functions that have<br>
// large bodies.<br>
if (RunPartialInlining)<br>
MPM.addPass(<wbr>PartialInlinerPass());<br>
<br>
- // Eliminate externally available functions now that inlining is over -- we<br>
- // won't emit these anyways.<br>
+ // Remove avail extern fns and globals definitions since we aren't compiling<br>
+ // an object file for later LTO. For LTO we want to preserve these so they<br>
+ // are eligible for inlining at link-time. Note if they are unreferenced they<br>
+ // will be removed by GlobalDCE later, so this only impacts referenced<br>
+ // available externally globals. Eventually they will be suppressed during<br>
+ // codegen, but eliminating here enables more opportunity for GlobalDCE as it<br>
+ // may make globals referenced by available external functions dead and saves<br>
+ // running remaining passes on the eliminated functions.<br>
MPM.addPass(<wbr>EliminateAvailableExternallyPa<wbr>ss());<br>
<br>
// Do RPO function attribute inference across the module to forward-propagate<br>
@@ -671,6 +684,87 @@ PassBuilder::<wbr>buildPerModuleDefaultPipeli<br>
}<br>
<br>
ModulePassManager<br>
+PassBuilder::<wbr>buildPerModuleDefaultPipeline(<wbr>OptimizationLevel Level,<br>
+ bool DebugLogging) {<br>
+ assert(Level != O0 && "Must request optimizations for the default pipeline!");<br>
+<br>
+ ModulePassManager MPM(DebugLogging);<br>
+<br>
+ // Force any function attributes we want the rest of the pipeline to observe.<br>
+ MPM.addPass(<wbr>ForceFunctionAttrsPass());<br>
+<br>
+ // Add the core simplification pipeline.<br>
+ MPM.addPass(<wbr>buildModuleSimplificationPipel<wbr>ine(Level, DebugLogging));<br>
+<br>
+ // Now add the optimization pipeline.<br>
+ MPM.addPass(<wbr>buildModuleOptimizationPipelin<wbr>e(Level, DebugLogging));<br>
+<br>
+ return MPM;<br>
+}<br>
+<br>
+ModulePassManager<br>
+PassBuilder::<wbr>buildThinLTOPreLinkDefaultPipe<wbr>line(OptimizationLevel Level,<br>
+ bool DebugLogging) {<br>
+ assert(Level != O0 && "Must request optimizations for the default pipeline!");<br>
+<br>
+ ModulePassManager MPM(DebugLogging);<br>
+<br>
+ // Force any function attributes we want the rest of the pipeline to observe.<br>
+ MPM.addPass(<wbr>ForceFunctionAttrsPass());<br>
+<br>
+ // If we are planning to perform ThinLTO later, we don't bloat the code with<br>
+ // unrolling/vectorization/... now. Just simplify the module as much as we<br>
+ // can.<br>
+ MPM.addPass(<wbr>buildModuleSimplificationPipel<wbr>ine(Level, DebugLogging));<br>
+<br>
+ // Run partial inlining pass to partially inline functions that have<br>
+ // large bodies.<br>
+ // FIXME: It isn't clear whether this is really the right place to run this<br>
+ // in ThinLTO. Because there is another canonicalization and simplification<br>
+ // phase that will run after the thin link, running this here ends up with<br>
+ // less information than will be available later and it may grow functions in<br>
+ // ways that aren't beneficial.<br>
+ if (RunPartialInlining)<br>
+ MPM.addPass(<wbr>PartialInlinerPass());<br>
+<br>
+ // Reduce the size of the IR as much as possible.<br>
+ MPM.addPass(GlobalOptPass());<br>
+<br>
+ // Rename anon globals to be able to export them in the summary.<br>
+ MPM.addPass(<wbr>NameAnonGlobalPass());<br>
+<br>
+ return MPM;<br>
+}<br>
+<br>
+ModulePassManager<br>
+PassBuilder::<wbr>buildThinLTODefaultPipeline(<wbr>OptimizationLevel Level,<br>
+ bool DebugLogging) {<br>
+ // FIXME: The summary index is not hooked in the new pass manager yet.<br>
+ // When it's going to be hooked, enable WholeProgramDevirt and LowerTypeTest<br>
+ // here.<br>
+<br>
+ ModulePassManager MPM(DebugLogging);<br>
+<br>
+ // Force any function attributes we want the rest of the pipeline to observe.<br>
+ MPM.addPass(<wbr>ForceFunctionAttrsPass());<br>
+<br>
+ // During the ThinLTO backend phase we perform early indirect call promotion<br>
+ // here, before globalopt. Otherwise imported available_externally functions<br>
+ // look unreferenced and are removed.<br>
+ MPM.addPass(<wbr>PGOIndirectCallPromotion(true /* InLTO */,<br>
+ PGOOpt && PGOOpt->SamplePGO &&<br>
+ !PGOOpt->ProfileUseFile.<wbr>empty()));<br>
+<br>
+ // Add the core simplification pipeline.<br>
+ MPM.addPass(<wbr>buildModuleSimplificationPipel<wbr>ine(Level, DebugLogging));<br>
+<br>
+ // Now add the optimization pipeline.<br>
+ MPM.addPass(<wbr>buildModuleOptimizationPipelin<wbr>e(Level, DebugLogging));<br>
+<br>
+ return MPM;<br>
+}<br>
+<br>
+ModulePassManager<br>
PassBuilder::<wbr>buildLTOPreLinkDefaultPipeline<wbr>(OptimizationLevel Level,<br>
bool DebugLogging) {<br>
assert(Level != O0 && "Must request optimizations for the default pipeline!");<br>
@@ -893,9 +987,16 @@ static Optional<int> parseDevirtPassName<br>
return Count;<br>
}<br>
<br>
+/// Tests whether a pass name starts with a valid prefix for a default pipeline<br>
+/// alias.<br>
+static bool startsWithDefaultPipelineAlias<wbr>Prefix(StringRef Name) {<br>
+ return Name.startswith("default") || Name.startswith("thinlto") ||<br>
+ Name.startswith("lto");<br>
+}<br>
+<br>
static bool isModulePassName(StringRef Name) {<br>
// Manually handle aliases for pre-configured pipeline fragments.<br>
- if (Name.startswith("default") || Name.startswith("lto"))<br>
+ if (<wbr>startsWithDefaultPipelineAlias<wbr>Prefix(Name))<br>
return DefaultAliasRegex.match(Name);<br>
<br>
// Explicitly handle pass manager names.<br>
@@ -1090,7 +1191,7 @@ bool PassBuilder::parseModulePass(<wbr>Module<br>
}<br>
<br>
// Manually handle aliases for pre-configured pipeline fragments.<br>
- if (Name.startswith("default") || Name.startswith("lto")) {<br>
+ if (<wbr>startsWithDefaultPipelineAlias<wbr>Prefix(Name)) {<br>
SmallVector<StringRef, 3> Matches;<br>
if (!DefaultAliasRegex.match(<wbr>Name, &Matches))<br>
return false;<br>
@@ -1109,6 +1210,10 @@ bool PassBuilder::parseModulePass(<wbr>Module<br>
<br>
if (Matches[1] == "default") {<br>
MPM.addPass(<wbr>buildPerModuleDefaultPipeline(<wbr>L, DebugLogging));<br>
+ } else if (Matches[1] == "thinlto-pre-link") {<br>
+ MPM.addPass(<wbr>buildThinLTOPreLinkDefaultPipe<wbr>line(L, DebugLogging));<br>
+ } else if (Matches[1] == "thinlto") {<br>
+ MPM.addPass(<wbr>buildThinLTODefaultPipeline(L, DebugLogging));<br>
} else if (Matches[1] == "lto-pre-link") {<br>
MPM.addPass(<wbr>buildLTOPreLinkDefaultPipeline<wbr>(L, DebugLogging));<br>
} else {<br>
<br>
Modified: llvm/trunk/test/Other/new-pm-<wbr>defaults.ll<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Other/new-pm-defaults.ll?rev=304407&r1=304406&r2=304407&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-<wbr>project/llvm/trunk/test/Other/<wbr>new-pm-defaults.ll?rev=304407&<wbr>r1=304406&r2=304407&view=diff</a><br>
==============================<wbr>==============================<wbr>==================<br>
--- llvm/trunk/test/Other/new-pm-<wbr>defaults.ll (original)<br>
+++ llvm/trunk/test/Other/new-pm-<wbr>defaults.ll Thu Jun 1 06:39:39 2017<br>
@@ -30,6 +30,8 @@<br>
; CHECK-O-NEXT: Running pass: PassManager<{{.*}}Module{{.*}}<wbr>><br>
; CHECK-O-NEXT: Starting llvm::Module pass manager run.<br>
; CHECK-O-NEXT: Running pass: ForceFunctionAttrsPass<br>
+; CHECK-O-NEXT: Running pass: PassManager<{{.*}}Module{{.*}}<wbr>><br>
+; CHECK-O-NEXT: Starting llvm::Module pass manager run.<br>
; CHECK-O-NEXT: Running pass: InferFunctionAttrsPass<br>
; CHECK-O-NEXT: Running analysis: TargetLibraryAnalysis<br>
; CHECK-O-NEXT: Running pass: ModuleToFunctionPassAdaptor<{{<wbr>.*}}PassManager{{.*}}><br>
@@ -53,7 +55,6 @@<br>
; CHECK-O-NEXT: Running pass: InstCombinePass<br>
; CHECK-O-NEXT: Running pass: SimplifyCFGPass<br>
; CHECK-O-NEXT: Finished llvm::Function pass manager run.<br>
-; CHECK-O-NEXT: Running pass: PGOIndirectCallPromotion<br>
; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}<wbr>GlobalsAA<br>
; CHECK-O-NEXT: Running analysis: GlobalsAA<br>
; CHECK-O-NEXT: Running analysis: CallGraphAnalysis<br>
@@ -134,6 +135,10 @@<br>
; CHECK-O-NEXT: Running pass: InstCombinePass<br>
; CHECK-O-NEXT: Finished llvm::Function pass manager run.<br>
; CHECK-O-NEXT: Finished CGSCC pass manager run.<br>
+; CHECK-O-NEXT: Finished llvm::Module pass manager run.<br>
+; CHECK-O-NEXT: Running pass: PassManager<{{.*}}Module{{.*}}<wbr>><br>
+; CHECK-O-NEXT: Starting llvm::Module pass manager run.<br>
+; CHECK-O-NEXT: Running pass: GlobalOptPass<br>
; CHECK-O-NEXT: Running pass: EliminateAvailableExternallyPa<wbr>ss<br>
; CHECK-O-NEXT: Running pass: ReversePostOrderFunctionAttrsP<wbr>ass<br>
; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}<wbr>GlobalsAA<br>
@@ -163,6 +168,7 @@<br>
; CHECK-O-NEXT: Running pass: GlobalDCEPass<br>
; CHECK-O-NEXT: Running pass: ConstantMergePass<br>
; CHECK-O-NEXT: Finished llvm::Module pass manager run.<br>
+; CHECK-O-NEXT: Finished llvm::Module pass manager run.<br>
; CHECK-O-NEXT: Running pass: PrintModulePass<br>
;<br>
; Make sure we get the IR back out without changes when we print the module.<br>
<br>
Copied: llvm/trunk/test/Other/new-pm-<wbr>thinlto-defaults.ll (from r304404, llvm/trunk/test/Other/new-pm-<wbr>defaults.ll)<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Other/new-pm-thinlto-defaults.ll?p2=llvm/trunk/test/Other/new-pm-thinlto-defaults.ll&p1=llvm/trunk/test/Other/new-pm-defaults.ll&r1=304404&r2=304407&rev=304407&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-<wbr>project/llvm/trunk/test/Other/<wbr>new-pm-thinlto-defaults.ll?p2=<wbr>llvm/trunk/test/Other/new-pm-<wbr>thinlto-defaults.ll&p1=llvm/<wbr>trunk/test/Other/new-pm-<wbr>defaults.ll&r1=304404&r2=<wbr>304407&rev=304407&view=diff</a><br>
==============================<wbr>==============================<wbr>==================<br>
--- llvm/trunk/test/Other/new-pm-<wbr>defaults.ll (original)<br>
+++ llvm/trunk/test/Other/new-pm-<wbr>thinlto-defaults.ll Thu Jun 1 06:39:39 2017<br>
@@ -6,30 +6,48 @@<br>
; to be invalidated.<br>
; Any invalidation that shows up here is a bug, unless we started modifying<br>
; the IR, in which case we need to make it immutable harder.<br>
-<br>
+;<br>
+; Prelink pipelines:<br>
+; RUN: opt -disable-verify -debug-pass-manager \<br>
+; RUN: -passes='thinlto-pre-link<O1><wbr>' -S %s 2>&1 \<br>
+; RUN: | FileCheck %s --check-prefixes=CHECK-O,<wbr>CHECK-O1,CHECK-PRELINK-O,<wbr>CHECK-PRELINK-O1<br>
; RUN: opt -disable-verify -debug-pass-manager \<br>
-; RUN: -passes='default<O1>' -S %s 2>&1 \<br>
-; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O1<br>
+; RUN: -passes='thinlto-pre-link<O2><wbr>' -S %s 2>&1 \<br>
+; RUN: | FileCheck %s --check-prefixes=CHECK-O,<wbr>CHECK-O2,CHECK-PRELINK-O,<wbr>CHECK-PRELINK-O2<br>
; RUN: opt -disable-verify -debug-pass-manager \<br>
-; RUN: -passes='default<O2>' -S %s 2>&1 \<br>
-; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O2<br>
+; RUN: -passes='thinlto-pre-link<O3><wbr>' -S %s 2>&1 \<br>
+; RUN: | FileCheck %s --check-prefixes=CHECK-O,<wbr>CHECK-O3,CHECK-PRELINK-O,<wbr>CHECK-PRELINK-O3<br>
; RUN: opt -disable-verify -debug-pass-manager \<br>
-; RUN: -passes='default<O3>' -S %s 2>&1 \<br>
-; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O3<br>
+; RUN: -passes='thinlto-pre-link<Os><wbr>' -S %s 2>&1 \<br>
+; RUN: | FileCheck %s --check-prefixes=CHECK-O,<wbr>CHECK-Os,CHECK-PRELINK-O,<wbr>CHECK-PRELINK-Os<br>
; RUN: opt -disable-verify -debug-pass-manager \<br>
-; RUN: -passes='default<Os>' -S %s 2>&1 \<br>
-; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-Os<br>
+; RUN: -passes='thinlto-pre-link<Oz><wbr>' -S %s 2>&1 \<br>
+; RUN: | FileCheck %s --check-prefixes=CHECK-O,<wbr>CHECK-Oz,CHECK-PRELINK-O,<wbr>CHECK-PRELINK-Oz<br>
+;<br>
+; Postlink pipelines:<br>
; RUN: opt -disable-verify -debug-pass-manager \<br>
-; RUN: -passes='default<Oz>' -S %s 2>&1 \<br>
-; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-Oz<br>
+; RUN: -passes='thinlto<O1>' -S %s 2>&1 \<br>
+; RUN: | FileCheck %s --check-prefixes=CHECK-O,<wbr>CHECK-O1,CHECK-POSTLINK-O,<wbr>CHECK-POSTLINK-O1<br>
; RUN: opt -disable-verify -debug-pass-manager \<br>
-; RUN: -passes='lto-pre-link<O2>' -S %s 2>&1 \<br>
-; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O2<br>
-<br>
+; RUN: -passes='thinlto<O2>' -S %s 2>&1 \<br>
+; RUN: | FileCheck %s --check-prefixes=CHECK-O,<wbr>CHECK-O2,CHECK-POSTLINK-O,<wbr>CHECK-POSTLINK-O2<br>
+; RUN: opt -disable-verify -debug-pass-manager \<br>
+; RUN: -passes='thinlto<O3>' -S %s 2>&1 \<br>
+; RUN: | FileCheck %s --check-prefixes=CHECK-O,<wbr>CHECK-O3,CHECK-POSTLINK-O,<wbr>CHECK-POSTLINK-O3<br>
+; RUN: opt -disable-verify -debug-pass-manager \<br>
+; RUN: -passes='thinlto<Os>' -S %s 2>&1 \<br>
+; RUN: | FileCheck %s --check-prefixes=CHECK-O,<wbr>CHECK-Os,CHECK-POSTLINK-O,<wbr>CHECK-POSTLINK-Os<br>
+; RUN: opt -disable-verify -debug-pass-manager \<br>
+; RUN: -passes='thinlto<Oz>' -S %s 2>&1 \<br>
+; RUN: | FileCheck %s --check-prefixes=CHECK-O,<wbr>CHECK-Oz,CHECK-POSTLINK-O,<wbr>CHECK-POSTLINK-Oz<br>
+;<br>
; CHECK-O: Starting llvm::Module pass manager run.<br>
; CHECK-O-NEXT: Running pass: PassManager<{{.*}}Module{{.*}}<wbr>><br>
; CHECK-O-NEXT: Starting llvm::Module pass manager run.<br>
; CHECK-O-NEXT: Running pass: ForceFunctionAttrsPass<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: PGOIndirectCallPromotion<br>
+; CHECK-O-NEXT: Running pass: PassManager<{{.*}}Module{{.*}}<wbr>><br>
+; CHECK-O-NEXT: Starting llvm::Module pass manager run.<br>
; CHECK-O-NEXT: Running pass: InferFunctionAttrsPass<br>
; CHECK-O-NEXT: Running analysis: TargetLibraryAnalysis<br>
; CHECK-O-NEXT: Running pass: ModuleToFunctionPassAdaptor<{{<wbr>.*}}PassManager{{.*}}><br>
@@ -53,7 +71,6 @@<br>
; CHECK-O-NEXT: Running pass: InstCombinePass<br>
; CHECK-O-NEXT: Running pass: SimplifyCFGPass<br>
; CHECK-O-NEXT: Finished llvm::Function pass manager run.<br>
-; CHECK-O-NEXT: Running pass: PGOIndirectCallPromotion<br>
; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}<wbr>GlobalsAA<br>
; CHECK-O-NEXT: Running analysis: GlobalsAA<br>
; CHECK-O-NEXT: Running analysis: CallGraphAnalysis<br>
@@ -134,37 +151,44 @@<br>
; CHECK-O-NEXT: Running pass: InstCombinePass<br>
; CHECK-O-NEXT: Finished llvm::Function pass manager run.<br>
; CHECK-O-NEXT: Finished CGSCC pass manager run.<br>
-; CHECK-O-NEXT: Running pass: EliminateAvailableExternallyPa<wbr>ss<br>
-; CHECK-O-NEXT: Running pass: ReversePostOrderFunctionAttrsP<wbr>ass<br>
-; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}<wbr>GlobalsAA<br>
-; CHECK-O-NEXT: Running pass: ModuleToFunctionPassAdaptor<{{<wbr>.*}}PassManager{{.*}}><br>
-; CHECK-O-NEXT: Starting llvm::Function pass manager run.<br>
-; CHECK-O-NEXT: Running pass: Float2IntPass<br>
-; CHECK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*<wbr>}}LoopRotatePass<br>
-; CHECK-O-NEXT: Running pass: LoopDistributePass<br>
-; CHECK-O-NEXT: Running pass: LoopVectorizePass<br>
-; CHECK-O-NEXT: Running analysis: BlockFrequencyAnalysis<br>
-; CHECK-O-NEXT: Running analysis: BranchProbabilityAnalysis<br>
-; CHECK-O-NEXT: Running pass: LoopLoadEliminationPass<br>
-; CHECK-O-NEXT: Running analysis: LoopAccessAnalysis<br>
-; CHECK-O-NEXT: Running pass: InstCombinePass<br>
-; CHECK-O-NEXT: Running pass: SLPVectorizerPass<br>
-; CHECK-O-NEXT: Running pass: SimplifyCFGPass<br>
-; CHECK-O-NEXT: Running pass: InstCombinePass<br>
-; CHECK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*<wbr>}}LoopUnrollPass<br>
-; CHECK-O-NEXT: Running pass: InstCombinePass<br>
-; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}<wbr>OptimizationRemarkEmitterAnaly<wbr>sis<br>
-; CHECK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*<wbr>}}LICMPass<br>
-; CHECK-O-NEXT: Running pass: AlignmentFromAssumptionsPass<br>
-; CHECK-O-NEXT: Running pass: LoopSinkPass<br>
-; CHECK-O-NEXT: Running pass: InstSimplifierPass<br>
-; CHECK-O-NEXT: Running pass: SimplifyCFGPass<br>
-; CHECK-O-NEXT: Finished llvm::Function pass manager run.<br>
-; CHECK-O-NEXT: Running pass: GlobalDCEPass<br>
-; CHECK-O-NEXT: Running pass: ConstantMergePass<br>
+; CHECK-O-NEXT: Finished llvm::Module pass manager run.<br>
+; CHECK-PRELINK-O-NEXT: Running pass: GlobalOptPass<br>
+; CHECK-PRELINK-O-NEXT: Running pass: NameAnonGlobalPass<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: PassManager<{{.*}}Module{{.*}}<wbr>><br>
+; CHECK-POSTLINK-O-NEXT: Starting llvm::Module pass manager run.<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: GlobalOptPass<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: EliminateAvailableExternallyPa<wbr>ss<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: ReversePostOrderFunctionAttrsP<wbr>ass<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}<wbr>GlobalsAA<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: ModuleToFunctionPassAdaptor<{{<wbr>.*}}PassManager{{.*}}><br>
+; CHECK-POSTLINK-O-NEXT: Starting llvm::Function pass manager run.<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: Float2IntPass<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*<wbr>}}LoopRotatePass<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: LoopDistributePass<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: LoopVectorizePass<br>
+; CHECK-POSTLINK-O-NEXT: Running analysis: BlockFrequencyAnalysis<br>
+; CHECK-POSTLINK-O-NEXT: Running analysis: BranchProbabilityAnalysis<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: LoopLoadEliminationPass<br>
+; CHECK-POSTLINK-O-NEXT: Running analysis: LoopAccessAnalysis<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: InstCombinePass<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: SLPVectorizerPass<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: SimplifyCFGPass<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: InstCombinePass<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*<wbr>}}LoopUnrollPass<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: InstCombinePass<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}<wbr>OptimizationRemarkEmitterAnaly<wbr>sis<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*<wbr>}}LICMPass<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: AlignmentFromAssumptionsPass<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: LoopSinkPass<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: InstSimplifierPass<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: SimplifyCFGPass<br>
+; CHECK-POSTLINK-O-NEXT: Finished llvm::Function pass manager run.<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: GlobalDCEPass<br>
+; CHECK-POSTLINK-O-NEXT: Running pass: ConstantMergePass<br>
+; CHECK-POSTLINK-O-NEXT: Finished llvm::Module pass manager run.<br>
; CHECK-O-NEXT: Finished llvm::Module pass manager run.<br>
; CHECK-O-NEXT: Running pass: PrintModulePass<br>
-;<br>
+<br>
; Make sure we get the IR back out without changes when we print the module.<br>
; CHECK-O-LABEL: define void @foo(i32 %n) local_unnamed_addr {<br>
; CHECK-O-NEXT: entry:<br>
<br>
Removed: llvm/trunk/test/ThinLTO/X86/<wbr>error-newpm.ll<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/test/ThinLTO/X86/error-newpm.ll?rev=304406&view=auto" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-<wbr>project/llvm/trunk/test/<wbr>ThinLTO/X86/error-newpm.ll?<wbr>rev=304406&view=auto</a><br>
==============================<wbr>==============================<wbr>==================<br>
--- llvm/trunk/test/ThinLTO/X86/<wbr>error-newpm.ll (original)<br>
+++ llvm/trunk/test/ThinLTO/X86/<wbr>error-newpm.ll (removed)<br>
@@ -1,13 +0,0 @@<br>
-; RUN: opt -module-summary %s -o %t1.bc<br>
-; RUN: not llvm-lto2 run %t1.bc -o %t.o \<br>
-; RUN: -r=%t1.bc,_tinkywinky,pxl \<br>
-; RUN: -lto-use-new-pm 2>&1 | FileCheck %s<br>
-<br>
-; CHECK: ThinLTO not supported with the new PM yet!<br>
-<br>
-target datalayout = "e-m:o-i64:64-f80:128-n8:16:<wbr>32:64-S128"<br>
-target triple = "x86_64-apple-macosx10.11.0"<br>
-<br>
-define void @tinkywinky() {<br>
- ret void<br>
-}<br>
<br>
Copied: llvm/trunk/test/ThinLTO/X86/<wbr>newpm-basic.ll (from r304404, llvm/trunk/test/ThinLTO/X86/<wbr>error-newpm.ll)<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/test/ThinLTO/X86/newpm-basic.ll?p2=llvm/trunk/test/ThinLTO/X86/newpm-basic.ll&p1=llvm/trunk/test/ThinLTO/X86/error-newpm.ll&r1=304404&r2=304407&rev=304407&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-<wbr>project/llvm/trunk/test/<wbr>ThinLTO/X86/newpm-basic.ll?p2=<wbr>llvm/trunk/test/ThinLTO/X86/<wbr>newpm-basic.ll&p1=llvm/trunk/<wbr>test/ThinLTO/X86/error-newpm.<wbr>ll&r1=304404&r2=304407&rev=<wbr>304407&view=diff</a><br>
==============================<wbr>==============================<wbr>==================<br>
--- llvm/trunk/test/ThinLTO/X86/<wbr>error-newpm.ll (original)<br>
+++ llvm/trunk/test/ThinLTO/X86/<wbr>newpm-basic.ll Thu Jun 1 06:39:39 2017<br>
@@ -1,9 +1,7 @@<br>
; RUN: opt -module-summary %s -o %t1.bc<br>
-; RUN: not llvm-lto2 run %t1.bc -o %t.o \<br>
+; RUN: llvm-lto2 run %t1.bc -o %t.o \<br>
; RUN: -r=%t1.bc,_tinkywinky,pxl \<br>
-; RUN: -lto-use-new-pm 2>&1 | FileCheck %s<br>
-<br>
-; CHECK: ThinLTO not supported with the new PM yet!<br>
+; RUN: -lto-use-new-pm<br>
<br>
target datalayout = "e-m:o-i64:64-f80:128-n8:16:<wbr>32:64-S128"<br>
target triple = "x86_64-apple-macosx10.11.0"<br>
<br>
<br>
______________________________<wbr>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-commits</a><br>
</blockquote></div></div></div></blockquote></div></div></div></div>
</blockquote></div><br></div></div>