summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Utils
Commit message (Collapse)AuthorAgeFilesLines
...
* [sanitizers] Disable target-specific lowering of string functions.Marcin Koscielnicki2016-06-181-0/+26
| | | | | | | | | | | | CodeGen has hooks that allow targets to emit specialized code instead of calls to memcmp, memchr, strcpy, stpcpy, strcmp, strlen, strnlen. When ASan/MSan/TSan/ESan is in use, this sidesteps its interceptors, resulting in uninstrumented memory accesses. To avoid that, make these sanitizers mark the calls as nobuiltin. Differential Revision: http://reviews.llvm.org/D19781 llvm-svn: 273083
* Use m_APInt in SimplifyCFGChuang-Yu Cheng2016-06-171-5/+5
| | | | | | | | | | | Switch from m_Constant to m_APInt per David's request. NFC. Author: Thomas Jablin (tjablin) Reviewers: majnemer cycheng http://reviews.llvm.org/D21440 llvm-svn: 272977
* [safestack] Fixup llvm.dbg.value when rewriting unsafe allocas.Evgeniy Stepanov2016-06-161-19/+73
| | | | | | | | | When moving unsafe allocas to the unsafe stack, dbg.declare intrinsics are updated to refer to the new location. This change does the same to dbg.value intrinsics. llvm-svn: 272968
* Revert r272891 "[JumpThreading] Prevent dangling pointer problems in ↵Igor Laevsky2016-06-161-5/+1
| | | | | | | | 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-161-1/+5
| | | | | | | | | 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
* [LAA] Default getInfo to not speculate symbolic strides. NFCAdam Nemet2016-06-161-1/+1
| | | | | | | Soon we won't be passing Strides to getInfo and then we'll have fewer call sites to update. llvm-svn: 272878
* 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
* Address review feedbacks of AddDiscriminator changeXinliang David Li2016-06-151-4/+6
| | | | llvm-svn: 272850
* [PM] Port Add discriminator pass to new PMXinliang David Li2016-06-152-9/+23
| | | | llvm-svn: 272847
* [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
* [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-143-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [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
* 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-122-2/+2
| | | | | | 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-121-1/+2
| | | | | | | | 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
* [LICM] Make isGuaranteedToExecute more accurate.Eli Friedman2016-06-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Make isGuaranteedToExecute use the isGuaranteedToTransferExecutionToSuccessor helper, and make that helper a bit more accurate. There's a potential performance impact here from assuming that arbitrary calls might not return. This probably has little impact on loads and stores to a pointer because most things alias analysis can reason about are dereferenceable anyway. The other impacts, like less aggressive hoisting of sdiv by a variable and less aggressive hoisting around volatile memory operations, are unlikely to matter for real code. This also impacts SCEV, which uses the same helper. It's a minor improvement there because we can tell that, for example, memcpy always returns normally. Strictly speaking, it's also introducing a bug, but it's not any worse than everywhere else we assume readonly functions terminate. Fixes http://llvm.org/PR27857. Reviewers: hfinkel, reames, chandlerc, sanjoy Subscribers: broune, llvm-commits Differential Revision: http://reviews.llvm.org/D21167 llvm-svn: 272489
* Delay dominator updation while cloning loop.Vikram TV2016-06-111-3/+9
| | | | | | | | | | | | | | | | | Summary: Dominator updation fails for a loop inserted with a new basicblock. A block required by DT to set the IDom might not have been cloned yet. This is because there is no predefined ordering of loop blocks (except for the header block which should be the first block in the list). The patch first creates DT nodes for the cloned blocks and then separately updates the DT in a follow-on loop. Reviewers: anemet, dberlin Subscribers: dberlin, llvm-commits Differential Revision: http://reviews.llvm.org/D20899 llvm-svn: 272479
* MemorySSA: fix memory access local dominance function for live on entrySebastian Pop2016-06-101-0/+15
| | | | | | | | | A memory access defined on function entry cannot be locally dominated by another memory access. The patch was split from http://reviews.llvm.org/D19338 which exposes the problem. Differential Revision: http://reviews.llvm.org/D21039 llvm-svn: 272436
* Move isGuaranteedToExecute out of LICM.Evgeniy Stepanov2016-06-101-0/+39
| | | | | | | Also rename LICMSafetyInfo to LoopSafetyInfo. Both will be used in LoopUnswitch in a separate change. llvm-svn: 272420
* [PM] Port LCSSA to the new PM.Easwaran Raman2016-06-093-20/+42
| | | | | | Differential Revision: http://reviews.llvm.org/D21090 llvm-svn: 272294
* Revert r272194 No need for it if loop Analysis Manager is usedXinliang David Li2016-06-091-1/+1
| | | | llvm-svn: 272243
* [LoopSimplify] Preserve LCSSA when merging exit blocks.Michael Zolotukhin2016-06-081-2/+21
| | | | | | | | | | | | | | Summary: This fixes PR26682. Also add LCSSA as a preserved pass to LoopSimplify, that looks correct to me and allows to write a test for the issue. Reviewers: chandlerc, bogner, sanjoy Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D21112 llvm-svn: 272224
* [LoopUnroll] Check that DT is available before trying to verify it.Michael Zolotukhin2016-06-081-1/+1
| | | | llvm-svn: 272221
* [PM] Refector LoopAccessInfo analysis code Xinliang David Li2016-06-081-1/+1
| | | | | | | | This is the preparation patch to port the analysis to new PM Differential Revision: http://reviews.llvm.org/D20560 llvm-svn: 272194
* [PM] LoopSimplify. Remove unneeded pass dependencies. NFCI.Davide Italiano2016-06-081-3/+0
| | | | llvm-svn: 272140
* [IndVars] Remove -liv-reduceSanjoy Das2016-06-051-72/+0
| | | | | | | | | | It is an off-by-default option that no one seems to use[0], and given that SCEV directly understands the overflow instrinsics there is no real need for it anymore. [0]: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098181.html llvm-svn: 271845
* [SimplifyCFG] Don't kill empty cleanuppads with multiple usesDavid Majnemer2016-06-041-0/+5
| | | | | | | | | | | | | | | | | A basic block could contain: %cp = cleanuppad [] cleanupret from %cp unwind to caller This basic block is empty and is thus a candidate for removal. However, there can be other uses of %cp outside of this basic block. This is only possible in unreachable blocks. Make our transform more correct by checking that the pad has a single user before removing the BB. This fixes PR28005. llvm-svn: 271816
* [MemorySSA] Port to new pass managerGeoff Berry2016-06-012-67/+56
| | | | | | | | | | | | | | | | | Add support for the new pass manager to MemorySSA pass. Change MemorySSA to be computed eagerly upon construction. Change MemorySSAWalker to be owned by the MemorySSA object that creates it. Reviewers: dberlin, george.burgess.iv Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D19664 llvm-svn: 271432
* IR: Allow multiple global metadata attachments with the same type.Peter Collingbourne2016-06-012-5/+6
| | | | | | | | | | This will be necessary to allow the global merge pass to attach multiple debug info metadata nodes to global variables once we reverse the edge from DIGlobalVariable to GlobalVariable. Differential Revision: http://reviews.llvm.org/D20414 llvm-svn: 271358
* Remove some 'const' specifiers that do nothing but prevent moving the argument.Benjamin Kramer2016-05-291-1/+1
| | | | | | | Found by clang-tidy's misc-move-const-arg. While there drop some obsolete c_str() calls. llvm-svn: 271181
* [IndVars] Eliminate op.with.overflow when possible (re-apply)Sanjoy Das2016-05-291-0/+107
| | | | | | | | | | | | | | | | | | | Summary: If we can prove that an op.with.overflow intrinsic does not overflow, we can get rid of the intrinsic, and replace it with non-wrapping arithmetic. This was first checked in at r265913 but reverted in r265950 because it exposed some issues around how SCEV handled post-inc add recurrences. Those issues have now been fixed. Reviewers: atrick, regehr Subscribers: sanjoy, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D18685 llvm-svn: 271153
* ValueMapper: fix assertion when null-mapping a constant for linking metadataMehdi Amini2016-05-281-3/+17
| | | | | | | | | | | | | | | | Summary: When RF_NullMapMissingGlobalValues is set, mapValue can return null for GlobalValue. When mapping the operands of a constant that is referenced from metadata, we need to handle this case and actually return null instead of mapping this constant. Reviewers: dexonsmith, rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D20713 llvm-svn: 271129
* The patch refactors unroll pass.Evgeny Stupachenko2016-05-271-3/+7
| | | | | | | | | | | | | | | | Summary: Unroll factor (Count) calculations moved to a new function. Early exits on pragma and "-unroll-count" defined factor added. New type of unrolling "Force" introduced (previously used implicitly). New unroll preference "AllowRemainder" introduced and set "true" by default. (should be set to false for architectures that suffers from it). Reviewers: hfinkel, mzolotukhin, zzheng Differential Revision: http://reviews.llvm.org/D19553 From: Evgeny Stupachenko <evstupac@gmail.com> llvm-svn: 271071
* [LCSSA] Simplify. Suggested by Sanjoy.Davide Italiano2016-05-271-1/+1
| | | | llvm-svn: 271041
* Vectorizer: track non-fast FP instructions through phis when finding reductions.Tim Northover2016-05-271-1/+1
| | | | | | | | When we traced through a phi node looking for floating-point reductions, we forgot whether we'd ever seen an instruction without fast-math flags (that would block vectorization). This propagates it through to the end. llvm-svn: 271015
* Avoid some copies by using const references.Benjamin Kramer2016-05-271-4/+4
| | | | | | | clang-tidy's performance-unnecessary-copy-initialization with some manual fixes. No functional changes intended. llvm-svn: 270988
* ValueMapper: fix typo in minor optimization on constant mapping (NFC)Mehdi Amini2016-05-271-1/+2
| | | | | | | | | | | | | | | | | If every operands of a constant are mapping to themselves, and the type does not change, we have an early exit as acknowledged in the comment: // Otherwise, we have some other constant to remap. Start by checking to see // if all operands have an identity remapping. However instead of checking for identity the code was checking if the operands were mapped to the constant itself, which is rarely true. As a consequence, the coverage report showed that the early exit was never taken. llvm-svn: 270944
* [InstCombine] Catch more bswap cases missed due to zext and truncs.Chad Rosier2016-05-261-4/+48
| | | | | | | Fixes PR27824. Differential Revision: http://reviews.llvm.org/D20591. llvm-svn: 270853
* MemorySSA: Revert r269678 and r268068; replace with special casing in MemorySSA.Peter Collingbourne2016-05-261-0/+8
| | | | | | | | | | | | | It turns out that too many passes are relying on alias analysis results for control dependencies. Until we fix that by introducing a more accurate modelling of control dependencies, special case assume in MemorySSA instead. Also introduce tests to ensure we don't regress the FunctionAttrs or LICM passes. Differential Revision: http://reviews.llvm.org/D20658 llvm-svn: 270823
* MemorySSA: Remove argument to createNewAccess function.Peter Collingbourne2016-05-261-4/+3
| | | | | | | | There is only one caller of MemorySSA::createNewAccess, and it passes true as the IgnoreNonMemory argument. Remove that argument and fold its behavior into createNewAccess. llvm-svn: 270812
* ValueMaterializer: rename materializeDeclFor() to materialize()Mehdi Amini2016-05-251-3/+3
| | | | | | | | | | It may materialize a declaration, or a definition. The name could be misleading. This is following a merge of materializeInitFor() into materializeDeclFor(). Differential Revision: http://reviews.llvm.org/D20593 llvm-svn: 270759
* ValueMaterializer: fuse materializeDeclFor and materializeInitFor (NFC)Mehdi Amini2016-05-251-7/+1
| | | | | | | | | | | | They were originally separated to handle the co-recursion between the ValueMapper and the ValueMaterializer. This recursion does not exist anymore: the ValueMapper now uses a Worklist and the ValueMaterializer is scheduling job on the Worklist. Differential Revision: http://reviews.llvm.org/D20593 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 270758
* Clarify that we match BSwap in InstCombine and BitReverse in CGP. NFC.Chad Rosier2016-05-251-1/+1
| | | | | | | | Also, rename recognizeBitReverseOrBSwapIdiom to recognizeBSwapOrBitReverseIdiom, so the ordering of the MatchBSwaps and MatchBitReversals arguments are consistent with the function name. llvm-svn: 270715
* Fix 80-column violation.Chad Rosier2016-05-211-1/+2
| | | | llvm-svn: 270329
* [SimplifyCFG] Remove cleanuppads which are empty except for calls to ↵David Majnemer2016-05-211-5/+17
| | | | | | | | | | | | | lifetime.end A cleanuppad is not cheap, they turn into many instructions and result in additional spills and fills. It is not worth keeping a cleanuppad around if all it does is hold a lifetime.end instruction. N.B. We first try to merge the cleanuppad with another cleanuppad to avoid dropping the lifetime and debug info markers. llvm-svn: 270314
* [SimplifyCFG] eliminate switch cases based on known range of switch conditionSanjay Patel2016-05-201-4/+10
| | | | | | | | | | | | This was noted in PR24766: https://llvm.org/bugs/show_bug.cgi?id=24766#c2 We may not know whether the sign bit(s) are zero or one, but we can still optimize based on knowing that the sign bit is repeated. Differential Revision: http://reviews.llvm.org/D20275 llvm-svn: 270222
OpenPOWER on IntegriCloud