summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* [PM] Port the always inliner to the new pass manager in a much moreChandler Carruth2016-08-177-21/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | minimal and boring form than the old pass manager's version. This pass does the very minimal amount of work necessary to inline functions declared as always-inline. It doesn't support a wide array of things that the legacy pass manager did support, but is alse ... about 20 lines of code. So it has that going for it. Notably things this doesn't support: - Array alloca merging - To support the above, bottom-up inlining with careful history tracking and call graph updates - DCE of the functions that become dead after this inlining. - Inlining through call instructions with the always_inline attribute. Instead, it focuses on inlining functions with that attribute. The first I've omitted because I'm hoping to just turn it off for the primary pass manager. If that doesn't pan out, I can add it here but it will be reasonably expensive to do so. The second should really be handled by running global-dce after the inliner. I don't want to re-implement the non-trivial logic necessary to do comdat-correct DCE of functions. This means the -O0 pipeline will have to be at least 'always-inline,global-dce', but that seems reasonable to me. If others are seriously worried about this I'd like to hear about it and understand why. Again, this is all solveable by factoring that logic into a utility and calling it here, but I'd like to wait to do that until there is a clear reason why the existing pass-based factoring won't work. The final point is a serious one. I can fairly easily add support for this, but it seems both costly and a confusing construct for the use case of the always inliner running at -O0. This attribute can of course still impact the normal inliner easily (although I find that a questionable re-use of the same attribute). I've started a discussion to sort out what semantics we want here and based on that can figure out if it makes sense ta have this complexity at O0 or not. One other advantage of this design is that it should be quite a bit faster due to checking for whether the function is a viable candidate for inlining exactly once per function instead of doing it for each call site. Anyways, hopefully a reasonable starting point for this pass. Differential Revision: https://reviews.llvm.org/D23299 llvm-svn: 278896
* IfConversion: Use references instead of pointers where possible; NFCMatthias Braun2016-08-171-124/+134
| | | | | | Also put some commonly used subexpressions into variables. llvm-svn: 278895
* IfConversion: Use range based for; NFCMatthias Braun2016-08-171-35/+23
| | | | | | | | Also avoid some pointless use of auto! Because that's friendlier to readers and avoids several types accidentally resolving to unnecessary references here (MachineInstr *&, unsigned &). llvm-svn: 278894
* IfConversion: Improve doxygen commentsMatthias Braun2016-08-171-63/+46
| | | | llvm-svn: 278893
* [Inliner] Add a flag to disable manual alloca merging in the Inliner.Chandler Carruth2016-08-171-49/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is off for now while testing can take place to make sure that in fact we do sufficient stack coloring to fully obviate the manual alloca array merging. Some context on why we should be using stack coloring rather than merging allocas in this way: LLVM relies very heavily on analyzing pointers as coming from different allocas in order to make aliasing decisions. These are some of the most powerful aliasing signals available in LLVM. So merging allocas is an extremely destructive operation on the LLVM IR -- it takes away highly valuable and hard to reconstruct information. As a consequence, inlined functions which happen to have array allocas that this pattern matches will fail to be properly interleaved unless SROA manages to hoist everything to an SSA register. Instead, the inliner will have added an unnecessary dependence that one inlined function execute after the other because they will have been rewritten to refer to the same memory. All that said, folks will reasonably want some time to experiment here and make sure there are no significant regressions. A flag should give us an easy knob to test. For more context, see the thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-July/103277.html http://lists.llvm.org/pipermail/llvm-dev/2016-August/103285.html Differential Revision: https://reviews.llvm.org/D23052 llvm-svn: 278892
* Some places that could using TargetParser in LLVM. NFC.Zijiao Ma2016-08-172-3/+8
| | | | llvm-svn: 278888
* Scalar: Avoid dereferencing end() in IndVarSimplifyDuncan P. N. Exon Smith2016-08-172-5/+10
| | | | | | | | | IndVarSimplify::sinkUnusedInvariants calls BasicBlock::getFirstInsertionPt on the ExitBlock and moves instructions before it. This can return end(), so it's not safe to dereference. Add an iterator-based overload to Instruction::moveBefore to avoid the UB. llvm-svn: 278886
* IPO: Swap || operands to avoid dereferencing end()Duncan P. N. Exon Smith2016-08-171-2/+2
| | | | | | | | IsOperandBundleUse conveniently indicates whether std::next(F->arg_begin(),UseIndex) will get to (or past) end(). Check it first to avoid dereferencing end(). llvm-svn: 278884
* Scalar: Avoid dereferencing end() in InductiveRangeCheckEliminationDuncan P. N. Exon Smith2016-08-171-3/+3
| | | | | | | | | BasicBlock::Create isn't designed to take iterators (which might be end()), but pointers (which might be nullptr). Fix the UB that was converting end() to a BasicBlock* by calling BasicBlock::getNextNode() in the first place. llvm-svn: 278883
* ObjCARC: Don't increment or dereference end() when scanning argsDuncan P. N. Exon Smith2016-08-171-33/+37
| | | | | | | | | When there's only one argument and it doesn't match one of the known functions, return ARCInstKind::CallOrUser rather than falling through to the two argument case. The old behaviour both incremented past and dereferenced end(). llvm-svn: 278881
* ARM: Avoid dereferencing end() in ARMFrameLowering::emitPrologueDuncan P. N. Exon Smith2016-08-171-1/+2
| | | | | | | | llvm::tryFoldSPUpdateIntoPushPop assumes its arguments are valid MachineInstrs. Update ARMFrameLowering::emitPrologue to respect that; when LastPush==end(), it can't possibly be a push instruction anyway. llvm-svn: 278880
* CodeGen: Avoid dereferencing end() in OptimizePHIs::OptimizeBBDuncan P. N. Exon Smith2016-08-171-1/+1
| | | | llvm-svn: 278879
* Hexagon: Avoid dereferencing end() in HexagonInstrInfo::InsertBranchDuncan P. N. Exon Smith2016-08-171-7/+5
| | | | llvm-svn: 278878
* AMDGPU: Avoid looking for the DebugLoc in end()Duncan P. N. Exon Smith2016-08-171-14/+12
| | | | | | | The end() iterator isn't a safe thing to dereference. Pass the DebugLoc into EmitFetchClause and EmitALUClause to avoid it. llvm-svn: 278873
* SimplifyCFG: Avoid dereferencing end()Duncan P. N. Exon Smith2016-08-161-1/+4
| | | | | | | | When comparing a User* to a BasicBlock::iterator in passingValueIsAlwaysUndefined, don't dereference the iterator in case it is end(). llvm-svn: 278872
* Revert "Write the TPI stream from a PDB to Yaml."Justin Bogner2016-08-166-144/+92
| | | | | | | | | This is hitting a "use of undeclared identifier 'skipPadding' error locally and on some bots. This reverts r278869. llvm-svn: 278871
* CodeGen: Avoid dereferencing end() when unconstifying iteratorsDuncan P. N. Exon Smith2016-08-161-8/+4
| | | | | | | | Rather than doing a funny dance that relies on dereferencing end() not crashing, add some API to MachineInstrBundleIterator to get a non-const version of the iterator. llvm-svn: 278870
* Write the TPI stream from a PDB to Yaml.Zachary Turner2016-08-166-92/+144
| | | | | | | Reviewed By: ruiu, rnk Differential Revision: https://reviews.llvm.org/D23226 llvm-svn: 278869
* Codegen: Don't tail-duplicate blocks with un-analyzable fallthrough.Kyle Butt2016-08-161-0/+10
| | | | | | | | | | | | If AnalyzeBranch can't analyze a block and it is possible to fallthrough, then duplicating the block doesn't make sense, as only one block can be the layout predecessor for the un-analyzable fallthrough. Submitted wit a test case, but NOTE: the test case doesn't currently fail. However, the test case fails with D20505 and would have saved me some time debugging. llvm-svn: 278866
* [InstCombine] clean up foldICmpAddConstant(); NFCISanjay Patel2016-08-161-44/+41
| | | | | | | | | | | 1. Fix variable names 2. Add local variables to reduce code 3. Fix code comments 4. Add early exit to reduce indentation 5. Remove 'else' after if -> return 6. Hoist common predicate llvm-svn: 278864
* [AMDGPU] Remove duplicate initialization of SIDebuggerInsertNops passKonstantin Zhuravlyov2016-08-161-1/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D23556 llvm-svn: 278863
* Preserve the assumption cache more oftenDavid Majnemer2016-08-162-18/+29
| | | | | | | We were clearing it out in LoopUnswitch and InlineFunction instead of attempting to preserve it. llvm-svn: 278860
* [InstCombine] use m_APInt to allow icmp (sub X, Y), C folds for splat ↵Sanjay Patel2016-08-161-15/+10
| | | | | | constant vectors llvm-svn: 278859
* CodeGen: Don't dereference end() in MachineBasicBlock::CorrectExtraCFGEdgesDuncan P. N. Exon Smith2016-08-161-4/+4
| | | | | | | | The current MachineBasicBlock might be the last block, so FallThru may be past the end(). Use getNextNode(), which will convert to nullptr, rather than &*++, which is invalid if we reach the end(). llvm-svn: 278858
* [x86] Allow merging multiple instances of an immediate within a basic block ↵Sanjay Patel2016-08-162-6/+9
| | | | | | | | | | | | | | for code size savings, for 64-bit constants. This patch handles 64-bit constants which can be encoded as 32-bit immediates. It extends the functionality added by https://reviews.llvm.org/D11363 for 32-bit constants to 64-bit constants. Patch by Sunita Marathe! Differential Revision: https://reviews.llvm.org/D23391 llvm-svn: 278857
* [libFuzzer] minor speed improvementKostya Serebryany2016-08-161-1/+1
| | | | llvm-svn: 278856
* [InstCombine] fix variable names to match formula comments; NFCSanjay Patel2016-08-161-17/+17
| | | | llvm-svn: 278855
* [LoopUnroll] Don't clear out the AssumptionCache on each loopDavid Majnemer2016-08-161-6/+8
| | | | | | | | | | | Clearing out the AssumptionCache can cause us to rescan the entire function for assumes. If there are many loops, then we are scanning over the entire function many times. Instead of clearing out the AssumptionCache, register all cloned assumes. llvm-svn: 278854
* Revert "Enhance SCEV to compute the trip count for some loops with unknown ↵Reid Kleckner2016-08-161-77/+4
| | | | | | | | stride." This reverts commit r278731. It caused http://crbug.com/638314 llvm-svn: 278853
* TailDuplicator: Use range loopsMatt Arsenault2016-08-161-42/+23
| | | | llvm-svn: 278847
* [AArch64] Adjust the scheduling model for Exynos M1.Evandro Menezes2016-08-161-14/+9
| | | | | | Refine the model for the FP division unit. llvm-svn: 278846
* [AArch64] Adjust the scheduling model for Exynos M1.Evandro Menezes2016-08-161-7/+11
| | | | | | Refine the model for the integer division unit. llvm-svn: 278845
* AMDGPU: Remove excessive padding from ImmOp and RegOp.Matt Arsenault2016-08-161-4/+4
| | | | | | | | | | | The structs ImmOp and RegOp are in AArch64AsmParser.cpp (inside anonymous namespace). This diff changes the order of fields and removes the excessive padding (8 bytes). Patch by Alexander Shaposhnikov llvm-svn: 278844
* [MBP] do not reorder and move up loop latch blockSjoerd Meijer2016-08-161-0/+10
| | | | | | | | | | Do not reorder and move up a loop latch block before a loop header when optimising for size because this will generate an extra unconditional branch. Differential Revision: https://reviews.llvm.org/D22521 llvm-svn: 278840
* [libFuzzer] new experimental feature: value profiling. Profiles values that ↵Kostya Serebryany2016-08-1615-11/+158
| | | | | | affect control flow and treats new values as new coverage. llvm-svn: 278839
* Remove excessive padding from LineNoCacheTyBenjamin Kramer2016-08-161-1/+1
| | | | | | | | | | | | The struct LineNoCacheTy is in SourceMgr.cpp inside anonymous namespace. This diff changes the order of fields and removes the excessive padding (8 bytes). Patch by Alexander Shaposhnikov! Differential revision: https://reviews.llvm.org/D23546 llvm-svn: 278838
* Make MDNode::intersect faster than O(n * m)David Majnemer2016-08-161-5/+4
| | | | | | | | It is pretty easy to get it down to O(nlogn + mlogm). This implementation has the added benefit of automatically deduplicating entries between the two sets. llvm-svn: 278837
* Don't passively concatenate MDNodesDavid Majnemer2016-08-161-13/+5
| | | | | | | | | | | I have audited all the callers of concatenate and none require duplicate entries to service concatenation. These duplicates serve no purpose but to needlessly embiggen the IR. N.B. Layering getMostGenericAliasScope on top of concatenate makes it O(nlogn + mlogm) instead of O(n*m). llvm-svn: 278836
* [Hexagon] Standardize next batch of pseudo instructionsKrzysztof Parzyszek2016-08-1610-74/+67
| | | | | | | | | | | | | ALIGNA PS_aligna ALLOCA PS_alloca TFR_FI PS_fi TFR_FIA PS_fia TFR_PdFalse PS_false TFR_PdTrue PS_true VMULW PS_vmulw VMULW_ACC PS_vmulw_acc llvm-svn: 278832
* [Coroutines] Part 7: Split coroutine into subfunctionsGor Nishanov2016-08-168-21/+783
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds simple coroutine splitting logic to CoroSplit pass. Documentation and overview is here: http://llvm.org/docs/Coroutines.html. Upstreaming sequence (rough plan) 1.Add documentation. (https://reviews.llvm.org/D22603) 2.Add coroutine intrinsics. (https://reviews.llvm.org/D22659) ... 7. Split coroutine into subfunctions <= we are here 8. Coroutine Frame Building algorithm 9. Handle coroutine with unwinds 10+. The rest of the logic Reviewers: majnemer Subscribers: llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D23461 llvm-svn: 278830
* [InstCombine] add helper functions for foldICmpWithConstant; NFCISanjay Patel2016-08-162-589/+726
| | | | | | | | | | | | | Besides breaking up a 700 line function to improve readability, this sinks the 'FIXME: ConstantInt' check into each helper. So now we can independently break that restriction within any of the helper functions. As much as possible, the code was only {cut/paste/clang-format}'ed to minimize risk (no functional changes intended), so several more readability improvements are still possible. llvm-svn: 278828
* [libFuzzer] refactoring around PCMap, NFCKostya Serebryany2016-08-165-81/+81
| | | | llvm-svn: 278825
* [mips] Enforce compact branch restrictionsSimon Dardis2016-08-161-13/+12
| | | | | | | | | | | Check both operands for use of the $zero register which cannot be used with a compact branch instruction. Reviewers: dsanders, vkalintris Differential Review: https://reviews.llvm.org/D23547 llvm-svn: 278824
* [Hexagon] Clean up some miscellaneous V60 intrinsics a bitKrzysztof Parzyszek2016-08-166-69/+58
| | | | llvm-svn: 278823
* When the inline spiller rematerializes an instruction, take the debug ↵Wolfgang Pieb2016-08-161-1/+7
| | | | | | | | | | | | location from the instruction that immediately follows the rematerialization point. Patch by Andrea DiBiagio. Differential Revision: http://reviews.llvm.org/D23539 llvm-svn: 278822
* [Asan] Unpoison red zones even if use-after-scope was disabled with runtime flagVitaly Buka2016-08-161-2/+3
| | | | | | | | | | | | Summary: PR27453 Reviewers: eugenis Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D23481 llvm-svn: 278818
* [InstCombine] use m_APInt in foldICmpWithConstant; NFCISanjay Patel2016-08-162-49/+46
| | | | | | | | | | | There's some formatting and pointer deref ugliness here that I intend to fix in subsequent patches. The overall goal is to refactor the obnoxiously long switch and incrementally remove the restriction to scalar types (allow folds for vector splats). This patch introduces the use of m_APInt which means the RHSV reference is now a pointer (and may have matched a vector splat), but the check of 'RHS' remains, so vector folds are disallowed and no functional change is intended. llvm-svn: 278816
* [Hexagon] Standardize vector predicate load/store pseudo instructionsKrzysztof Parzyszek2016-08-163-67/+32
| | | | | | | | | | | | - Remove unused instructions: LDriq_pred_vec_V6, STriq_pred_vec_V6, and the 128B counterparts. - Rename: LDriq_pred_V6 PS_vloadrq_ai LDriq_pred_V6_128B PS_vloadrq_ai_128B STriq_pred_V6 PS_vstorerq_ai STriq_pred_V6_128B PS_vstorerq_ai_128B llvm-svn: 278813
* [AArch64][GlobalISel] Select G_MUL.Ahmed Bougacha2016-08-162-0/+41
| | | | llvm-svn: 278810
* [AArch64][GlobalISel] Factor out unsupported binop check. NFC.Ahmed Bougacha2016-08-161-40/+50
| | | | | | | We're going to need it for G_MUL, and, if other targets end up using something similar, we can easily put it in the generic selector. llvm-svn: 278808
OpenPOWER on IntegriCloud