From aa641a51719eed9509566e8352bf59e75e2c81b4 Mon Sep 17 00:00:00 2001 From: Andrew Kaylor Date: Fri, 22 Apr 2016 22:06:11 +0000 Subject: Re-commit optimization bisect support (r267022) without new pass manager support. The original commit was reverted because of a buildbot problem with LazyCallGraph::SCC handling (not related to the OptBisect handling). Differential Revision: http://reviews.llvm.org/D19172 llvm-svn: 267231 --- llvm/lib/Transforms/IPO/FunctionAttrs.cpp | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'llvm/lib/Transforms/IPO/FunctionAttrs.cpp') diff --git a/llvm/lib/Transforms/IPO/FunctionAttrs.cpp b/llvm/lib/Transforms/IPO/FunctionAttrs.cpp index ec6062a..91768f5 100644 --- a/llvm/lib/Transforms/IPO/FunctionAttrs.cpp +++ b/llvm/lib/Transforms/IPO/FunctionAttrs.cpp @@ -1081,6 +1081,9 @@ INITIALIZE_PASS_END(PostOrderFunctionAttrsLegacyPass, "functionattrs", Pass *llvm::createPostOrderFunctionAttrsLegacyPass() { return new PostOrderFunctionAttrsLegacyPass(); } bool PostOrderFunctionAttrsLegacyPass::runOnSCC(CallGraphSCC &SCC) { + if (skipSCC(SCC)) + return false; + TLI = &getAnalysis().getTLI(); bool Changed = false; @@ -1195,6 +1198,9 @@ static bool addNoRecurseAttrsTopDown(Function &F) { } bool ReversePostOrderFunctionAttrs::runOnModule(Module &M) { + if (skipModule(M)) + return false; + // We only have a post-order SCC traversal (because SCCs are inherently // discovered in post-order), so we accumulate them in a vector and then walk // it in reverse. This is simpler than using the RPO iterator infrastructure -- cgit v1.1