summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* Revert r272891 "[JumpThreading] Prevent dangling pointer problems in ↵Igor Laevsky2016-06-162-17/+5
| | | | | | | | BranchProbabilityInfo" It was causing failures in Profile-i386 and Profile-x86_64 tests. llvm-svn: 272912
* [JumpThreading] Prevent dangling pointer problems in BranchProbabilityInfoIgor Laevsky2016-06-162-5/+17
| | | | | | | | | We should update results of the BranchProbabilityInfo after removing block in JumpThreading. Otherwise we will get dangling pointer inside BranchProbabilityInfo cache. Differential Revision: http://reviews.llvm.org/D20957 llvm-svn: 272891
* PR27938: Don't remove valid DebugLoc in ScalarizerPatrik Hagglund2016-06-161-1/+2
| | | | | | | | | | | | | | | | | Added checks to make sure the Scalarizer::transferMetadata() don't remove valid debug locations from instructions. This is important as the verifier pass require that e.g. inlinable callsites have a valid debug location. https://llvm.org/bugs/show_bug.cgi?id=27938 Patch by Karl-Johan Karlsson Reviewers: dblaikie Differential Revision: http://reviews.llvm.org/D20807 llvm-svn: 272884
* [LAA] Default getInfo to not speculate symbolic strides. NFCAdam Nemet2016-06-163-3/+3
| | | | | | | Soon we won't be passing Strides to getInfo and then we'll have fewer call sites to update. llvm-svn: 272878
* Attempt to define friend function more portably.Sean Silva2016-06-161-16/+5
| | | | | | Patch written by Reid. I verified it locally with clang. llvm-svn: 272875
* SimplifyCFG is able to detect the pattern:Chuang-Yu Cheng2016-06-161-4/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (i == 5334 || i == 5335) to: ((i & -2) == 5334) This transformation has some incorrect side conditions. Specifically, the transformation is only applied when the right-hand side constant (5334 in the example) is a power of two not equal and not equal to the negated mask. These side conditions were added in r258904 to fix PR26323. The correct side condition is that: ((Constant & Mask) == Constant)[(5334 & -2) == 5334]. It's a little bit hard to see why these transformations are correct and what the side conditions ought to be. Here is a CVC3 program to verify them for 64-bit values: ONE : BITVECTOR(64) = BVZEROEXTEND(0bin1, 63); x : BITVECTOR(64); y : BITVECTOR(64); z : BITVECTOR(64); mask : BITVECTOR(64) = BVSHL(ONE, z); QUERY( (y & ~mask = y) => ((x & ~mask = y) <=> (x = y OR x = (y | mask))) ); Please note that each pattern must be a dual implication (<--> or iff). One directional implication can create spurious matches. If the implication is only one-way, an unsatisfiable condition on the left side can imply a satisfiable condition on the right side. Dual implication ensures that satisfiable conditions are transformed to other satisfiable conditions and unsatisfiable conditions are transformed to other unsatisfiable conditions. Here is a concrete example of a unsatisfiable condition on the left implying a satisfiable condition on the right: mask = (1 << z) (x & ~mask) == y --> (x == y || x == (y | mask)) Substituting y = 3, z = 0 yields: (x & -2) == 3 --> (x == 3 || x == 2) The version of this code before r258904 had no side-conditions and incorrectly justified itself in comments through one-directional implication. Thanks to Chandler for the suggestion! Author: Thomas Jablin (tjablin) Reviewers: chandlerc majnemer hfinkel cycheng http://reviews.llvm.org/D21417 llvm-svn: 272873
* [InstCombine] Don't widen metadata on store-to-load forwardingEli Friedman2016-06-161-2/+4
| | | | | | | | | | | | | The original check for load CSE or store-to-load forwarding is wrong when the forwarded stored value happened to be a load. Ref https://github.com/JuliaLang/julia/issues/16894 Differential Revision: http://reviews.llvm.org/D21271 Patch by Yichao Yu! llvm-svn: 272868
* [IR] [DAE] Copy comdats during DAE, and don't copy comdats in ↵Justin Lebar2016-06-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | GlobalObject::copyAttributesFrom. Summary: This reverts the changes to Globals.cpp and IRMover.cpp in "[IR] Copy comdats in GlobalObject::copyAttributesFrom" (D20631, rL270743). The DeadArgElim test is left unchanged, and we change DAE to explicitly copy comdats. The reverted change breaks copyAttributesFrom when the destination lives in a different module from the source. The decision in D21255 was to revert this patch and handle comdat copying separately from copyAttributesFrom. Reviewers: majnemer, rnk Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D21403 llvm-svn: 272855
* [LV] Make the new getter return a const reference. NFCAdam Nemet2016-06-151-1/+3
| | | | | | | | | LoopVectorizationLegality holds a constant reference to LAI, so this will have to be const as well. Also added missed function comment. llvm-svn: 272851
* Address review feedbacks of AddDiscriminator changeXinliang David Li2016-06-151-4/+6
| | | | llvm-svn: 272850
* [DSE] Hoist a redundant check to simplify logic. NFC.Chad Rosier2016-06-151-12/+5
| | | | llvm-svn: 272849
* [PM] Port Add discriminator pass to new PMXinliang David Li2016-06-152-9/+23
| | | | llvm-svn: 272847
* Typo. NFC.Chad Rosier2016-06-151-1/+1
| | | | llvm-svn: 272846
* [PM] Remove unneded doFinalization() override from LoopVersioningLICM.Davide Italiano2016-06-151-4/+0
| | | | llvm-svn: 272842
* [LoopSimplify] Analyses do not need to be member variables.Davide Italiano2016-06-151-9/+6
| | | | | | In preparation for porting this pass to the new PM. llvm-svn: 272818
* [LV] Add getter function for LoopVectorizationLegality::Strides. NFCAdam Nemet2016-06-151-6/+8
| | | | | | This should help moving Strides to LAA later. llvm-svn: 272796
* [LV] Remove more unused functions. NFCAdam Nemet2016-06-151-4/+0
| | | | | | LoopVectorizationLegality::strides_begin/end are also unused. llvm-svn: 272781
* [LV] Remove unused function. NFCAdam Nemet2016-06-151-1/+0
| | | | | | LoopVectorizationLegality::mustCheckStrides is unused. llvm-svn: 272780
* Work around MSVC "friend" semantics.Sean Silva2016-06-151-0/+2
| | | | | | | | | | | | The error on clang-x86-win2008-selfhost is: C:\buildbot\slave-config\clang-x86-win2008-selfhost\llvm\lib\Transforms\Vectorize\SLPVectorizer.cpp(955) : error C2248: 'llvm::slpvectorizer::BoUpSLP::ScheduleData' : cannot access private struct declared in class 'llvm::slpvectorizer::BoUpSLP' C:\buildbot\slave-config\clang-x86-win2008-selfhost\llvm\lib\Transforms\Vectorize\SLPVectorizer.cpp(608) : see declaration of 'llvm::slpvectorizer::BoUpSLP::ScheduleData' C:\buildbot\slave-config\clang-x86-win2008-selfhost\llvm\lib\Transforms\Vectorize\SLPVectorizer.cpp(337) : see declaration of 'llvm::slpvectorizer::BoUpSLP' I reproduced this locally with both MSVC 2013 and MSVC 2015. llvm-svn: 272772
* Speculative buildbot fix.Sean Silva2016-06-151-0/+5
| | | | | | | | | | | | | | This wasn't failing for me with clang as the compiler. I think GCC may disagree with clang about whether a friend declaration introduces a declaration in the enclosing namespace (or something). Example error: /home/uweigand/sandbox/buildbot/clang-s390x-linux/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:950:77: error: ‘llvm::raw_ostream& llvm::slpvectorizer::operator<<(llvm::raw_ostream&, const llvm::slpvectorizer::BoUpSLP::ScheduleData&)’ should have been declared inside ‘llvm::slpvectorizer’ const BoUpSLP::ScheduleData &SD) { ^ llvm-svn: 272767
* [PM] Port SLPVectorizer to the new PMSean Silva2016-06-151-138/+113
| | | | | | | | | | | This uses the "runImpl" approach to share code with the old PM. Porting to the new PM meant abandoning the anonymous namespace enclosing most of SLPVectorizer.cpp which is a bit of a bummer (but not a big deal compared to having to pull the pass class into a header which the new PM requires since it calls the constructor directly). llvm-svn: 272766
* [PM] Port AlignmentFromAssumptions to the new PM.Sean Silva2016-06-151-21/+36
| | | | | | This uses the "runImpl" pattern to share code between the old and new PM. llvm-svn: 272757
* Recommit [LV] Enable vectorization of loops where the IV has an external useMichael Kuperstein2016-06-151-26/+92
| | | | | | | | | | | | | r272715 broke libcxx because it did not correctly handle cases where the last iteration of one IV is the second-to-last iteration of another. Original commit message: Vectorizing loops with "escaping" IVs has been disabled since r190790, due to PR17179. This re-enables it, with support for external use of both "post-increment" (last iteration) and "pre-increment" (second-to-last iteration) IVs. llvm-svn: 272742
* [LoopUnroll] Don't crash trying to unroll loop with EH pad exitDavid Majnemer2016-06-151-0/+5
| | | | | | | | | | | | | | We do not support splitting cleanuppad or catchswitches. This is problematic for passes which assume that a loop is in loop simplify form (the loop would have a dedicated exit block instead of sharing it). While it isn't great that we don't support this for cleanups, we still cannot make loop-simplify form an assertable precondition because indirectbr will also disable these sorts of CFG cleanups. This fixes PR28132. llvm-svn: 272739
* Remove the ScalarReplAggregates passDavid Majnemer2016-06-155-2641/+7
| | | | | | | | | | Nearly all the changes to this pass have been done while maintaining and updating other parts of LLVM. LLVM has had another pass, SROA, which has superseded ScalarReplAggregates for quite some time. Differential Revision: http://reviews.llvm.org/D21316 llvm-svn: 272737
* Reverting r272715 since it broke libcxx.Michael Kuperstein2016-06-141-80/+26
| | | | llvm-svn: 272730
* [PM] Port WholeProgramDevirt to the new pass manager.Davide Italiano2016-06-141-0/+6
| | | | llvm-svn: 272721
* [LV] Enable vectorization of loops where the IV has an external useMichael Kuperstein2016-06-141-26/+80
| | | | | | | | | | | Vectorizing loops with "escaping" IVs has been disabled since r190790, due to PR17179. This re-enables it, with support for external use of both "post-increment" (last iteration) and "pre-increment" (second-to-last iteration) IVs. Differential Revision: http://reviews.llvm.org/D21048 llvm-svn: 272715
* [MemorySSA] Set CFGOnly correctly for MemorySSAWrapperPassGeoff Berry2016-06-141-2/+3
| | | | | | | | Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D21344 llvm-svn: 272712
* IR: Introduce local_unnamed_addr attribute.Peter Collingbourne2016-06-1411-26/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
* LoopRotate: restructure code to simplify functionsSebastian Pop2016-06-141-41/+59
| | | | | | | | | | | | We move the loop rotate functions in a separate class to avoid passing multiple parameters to each function. This cleanup will help with further development of loop rotation. NFC. Patch written by Aditya Kumar and Sebastian Pop. Differential Revision: http://reviews.llvm.org/D21311 llvm-svn: 272672
* [MergedLoadStoreMotion] Before quering AA verify the loads are the same.Chad Rosier2016-06-141-1/+1
| | | | | | | Basicaa stats show the number of queries in Spec2k6 are reduced by 4540 or ~.67% overall. llvm-svn: 272661
* [LoopVer] Remove an assert that's redundant now. NFCAdam Nemet2016-06-141-4/+1
| | | | | | | | Ensuring that the PHI are all single-operand is not performed in the second pass added by the previous pass. This removes the assert from the first pass. llvm-svn: 272650
* [LoopVer] Update all existing PHIs in the exit blockAdam Nemet2016-06-141-6/+18
| | | | | | | | | | | | | | | | | | | | | | We only used to add the edge from the cloned loop to PHIs that corresponded to values defined by the loop. We need to do this for all PHIs obviously since we need a PHI operand for each incoming edge. This includes things like PHIs with a constant value or with values defined before the original loop (see the testcases). After the patch the PHIs are added to the exit block in two passes. In the first pass we ensure there is a single-operand (LCSSA) PHI for each value defined by the loop. In the second pass we loop through each (single-operand) PHI and add the value for the edge from the cloned loop. If the value is defined in the loop we'll use the cloned instruction from the cloned loop. Fixes PR28037 llvm-svn: 272649
* [PM] Port Mem2Reg to the new pass manager.Davide Italiano2016-06-142-51/+67
| | | | llvm-svn: 272630
* [PM] Port MemCpyOpt to the new PM.Sean Silva2016-06-142-57/+97
| | | | | | | | | The need for all these Lookup* functions is just because of calls to getAnalysis inside methods (i.e. not at the top level) of the runOnFunction method. They should be straightforward to clean up when the old PM is gone. llvm-svn: 272615
* [PM/MergedLoadStoreMotion] Preserve analyses more aggressively.Davide Italiano2016-06-141-1/+6
| | | | llvm-svn: 272611
* Bring back "[PM] Port JumpThreading to the new PM" with a fixSean Silva2016-06-141-113/+82
| | | | | | | | | | | This reverts commit r272603 and adds a fix. Big thanks to Davide for pointing me at r216244 which gives some insight into how to fix this VS2013 issue. VS2013 can't synthesize a move constructor. So the fix here is to add one explicitly to the JumpThreadingPass class. llvm-svn: 272607
* [PM] Port MergedLoadStoreMotion to the new pass manager.Davide Italiano2016-06-142-49/+62
| | | | llvm-svn: 272606
* Revert "[PM] Port JumpThreading to the new PM"Sean Silva2016-06-141-82/+113
| | | | | | | | This reverts commit r272597. Will investigate issue with VS2013 compilation and then recommit. llvm-svn: 272603
* [PM/MergedLoadStoreMotion] Remove unneeded pass dependency.Davide Italiano2016-06-131-1/+0
| | | | llvm-svn: 272598
* [PM] Port JumpThreading to the new PMSean Silva2016-06-131-113/+82
| | | | | | | | | | | | This follows the approach in r263208 (for GVN) pretty closely: - move the bulk of the body of the function to the new PM class. - expose a runImpl method on the new-PM class that takes the IRUnitT and pointers/references to any analyses and use that to implement the old-PM class. - use a private namespace in the header for stuff that used to be file scope llvm-svn: 272597
* [PM/MergeLoadStoreMotion] Convert the logic to static functions.Davide Italiano2016-06-131-85/+63
| | | | | | | Pass AliasAnalyis and MemoryDepResult around. This is in preparation for porting this pass to the new PM. llvm-svn: 272595
* [PM] Port LVI to the new PM.Sean Silva2016-06-132-7/+7
| | | | | | | | | | | | | | | | | | | This is a bit gnarly since LVI is maintaining its own cache. I think this port could be somewhat cleaner, but I'd rather not spend too much time on it while we still have the old pass hanging around and limiting how much we can clean things up. Once the old pass is gone it will be easier (less time spent) to clean it up anyway. This is the last dependency needed for porting JumpThreading which I'll do in a follow-up commit (there's no printer pass for LVI or anything to test it, so porting a pass that depends on it seems best). I've been mostly following: r269370 / D18834 which ported Dependence Analysis r268601 / D19839 which ported BPI llvm-svn: 272593
* Fix a typo in loop versioning.Vikram TV2016-06-131-1/+1
| | | | | | | | | | Reviewers: ashutosh.nema Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D21281 llvm-svn: 272545
* Run clang-tidy's performance-unnecessary-copy-initialization over LLVM.Benjamin Kramer2016-06-121-1/+1
| | | | | | No functionality change intended. llvm-svn: 272516
* Move instances of std::function.Benjamin Kramer2016-06-123-3/+3
| | | | | | Or replace with llvm::function_ref if it's never stored. NFC intended. llvm-svn: 272513
* Pass DebugLoc and SDLoc by const ref.Benjamin Kramer2016-06-122-2/+3
| | | | | | | | This used to be free, copying and moving DebugLocs became expensive after the metadata rewrite. Passing by reference eliminates a ton of track/untrack operations. No functionality change intended. llvm-svn: 272512
* [PM] Port DeadArgumentElimination to the new PMSean Silva2016-06-121-120/+49
| | | | | | | | | The approach taken here follows r267631. deadarghaX0r should be easy to port when the time comes to add new-PM support to bugpoint. llvm-svn: 272507
* [PM] Port ReversePostOrderFunctionAttrs to the new PMSean Silva2016-06-122-19/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Below are my super rough notes when porting. They can probably serve as a basic guide for porting other passes to the new PM. As I port more passes I'll expand and generalize this and make a proper docs/HowToPortToNewPassManager.rst document. There is also missing documentation for general concepts and API's in the new PM which will require some documentation. Once there is proper documentation in place we can put up a list of passes that have to be ported and game-ify/crowdsource the rest of the porting (at least of the middle end; the backend is still unclear). I will however be taking personal responsibility for ensuring that the LLD/ELF LTO pipeline is ported in a timely fashion. The remaining passes to be ported are (do something like `git grep "<the string in the bullet point below>"` to find the pass): General Scalar: [ ] Simplify the CFG [ ] Jump Threading [ ] MemCpy Optimization [ ] Promote Memory to Register [ ] MergedLoadStoreMotion [ ] Lazy Value Information Analysis General IPO: [ ] Dead Argument Elimination [ ] Deduce function attributes in RPO Loop stuff / vectorization stuff: [ ] Alignment from assumptions [ ] Canonicalize natural loops [ ] Delete dead loops [ ] Loop Access Analysis [ ] Loop Invariant Code Motion [ ] Loop Vectorization [ ] SLP Vectorizer [ ] Unroll loops Devirtualization / CFI: [ ] Cross-DSO CFI [ ] Whole program devirtualization [ ] Lower bitset metadata CGSCC passes: [ ] Function Integration/Inlining [ ] Remove unused exception handling info [ ] Promote 'by reference' arguments to scalars Please let me know if you are interested in working on any of the passes in the above list (e.g. reply to the post-commit thread for this patch). I'll probably be tackling "General Scalar" and "General IPO" first FWIW. Steps as I port "Deduce function attributes in RPO" --------------------------------------------------- (note: if you are doing any work based on these notes, please leave a note in the post-commit review thread for this commit with any improvements / suggestions / incompleteness you ran into!) Note: "Deduce function attributes in RPO" is a module pass. 1. Do preparatory refactoring. Do preparatory factoring. In this case all I had to do was to pull out a static helper (r272503). (TODO: give more advice here e.g. if pass holds state or something) 2. Rename the old pass class. llvm/lib/Transforms/IPO/FunctionAttrs.cpp Rename class ReversePostOrderFunctionAttrs -> ReversePostOrderFunctionAttrsLegacyPass in preparation for adding a class ReversePostOrderFunctionAttrs as the pass in the new PM. (edit: actually wait what? The new class name will be ReversePostOrderFunctionAttrsPass, so it doesn't conflict. So this step is sort of useless churn). llvm/include/llvm/InitializePasses.h llvm/lib/LTO/LTOCodeGenerator.cpp llvm/lib/Transforms/IPO/IPO.cpp llvm/lib/Transforms/IPO/FunctionAttrs.cpp Rename initializeReversePostOrderFunctionAttrsPass -> initializeReversePostOrderFunctionAttrsLegacyPassPass (note that the "PassPass" thing falls out of `s/ReversePostOrderFunctionAttrs/ReversePostOrderFunctionAttrsLegacyPass/`) Note that the INITIALIZE_PASS macro is what creates this identifier name, so renaming the class requires this renaming too. Note that createReversePostOrderFunctionAttrsPass does not need to be renamed since its name is not generated from the class name. 3. Add the new PM pass class. In the new PM all passes need to have their declaration in a header somewhere, so you will often need to add a header. In this case llvm/include/llvm/Transforms/IPO/FunctionAttrs.h is already there because PostOrderFunctionAttrsPass was already ported. The file-level comment from the .cpp file can be used as the file-level comment for the new header. You may want to tweak the wording slightly from "this file implements" to "this file provides" or similar. Add declaration for the new PM pass in this header: class ReversePostOrderFunctionAttrsPass : public PassInfoMixin<ReversePostOrderFunctionAttrsPass> { public: PreservedAnalyses run(Module &M, AnalysisManager<Module> &AM); }; Its name should end with `Pass` for consistency (note that this doesn't collide with the names of most old PM passes). E.g. call it `<name of the old PM pass>Pass`. Also, move the doxygen comment from the old PM pass to the declaration of this class in the header. Also, include the declaration for the new PM class `llvm/Transforms/IPO/FunctionAttrs.h` at the top of the file (in this case, it was already done when the other pass in this file was ported). Now define the `run` method for the new class. The main things here are: a) Use AM.getResult<...>(M) to get results instead of `getAnalysis<...>()` b) If the old PM pass would have returned "false" (i.e. `Changed == false`), then you should return PreservedAnalyses::all(); c) In the old PM getAnalysisUsage method, observe the calls `AU.addPreserved<...>();`. In the case `Changed == true`, for each preserved analysis you should do call `PA.preserve<...>()` on a PreservedAnalyses object and return it. E.g.: PreservedAnalyses PA; PA.preserve<CallGraphAnalysis>(); return PA; Note that calls to skipModule/skipFunction are not supported in the new PM currently, so optnone and optimization bisect support do not work. You can just drop those calls for now. 4. Add the pass to the new PM pass registry to make it available in opt. In llvm/lib/Passes/PassBuilder.cpp add a #include for your header. `#include "llvm/Transforms/IPO/FunctionAttrs.h"` In this case there is already an include (from when PostOrderFunctionAttrsPass was ported). Add your pass to llvm/lib/Passes/PassRegistry.def In this case, I added `MODULE_PASS("rpo-functionattrs", ReversePostOrderFunctionAttrsPass())` The string is from the `INITIALIZE_PASS*` macros used in the old pass manager. Then choose a test that uses the pass and use the new PM `-passes=...` to run it. E.g. in this case there is a test that does: ; RUN: opt < %s -basicaa -functionattrs -rpo-functionattrs -S | FileCheck %s I have added the line: ; RUN: opt < %s -aa-pipeline=basic-aa -passes='require<targetlibinfo>,cgscc(function-attrs),rpo-functionattrs' -S | FileCheck %s The `-aa-pipeline=basic-aa` and `require<targetlibinfo>,cgscc(function-attrs)` are what is needed to run functionattrs in the new PM (note that in the new PM "functionattrs" becomes "function-attrs" for some reason). This is just pulled from `readattrs.ll` which contains the change from when functionattrs was ported to the new PM. Adding rpo-functionattrs causes the pass that was just ported to run. llvm-svn: 272505
OpenPOWER on IntegriCloud