summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
...
* Resubmit: [Salvage] Change salvage debug info implementation to use ↵Stephen Tozer2019-05-161-2/+21
| | | | | | | | | | | | | | | | | | DW_OP_LLVM_convert where needed Fixes issue: https://bugs.llvm.org/show_bug.cgi?id=40645 Previously, LLVM had no functional way of performing casts inside of a DIExpression(), which made salvaging cast instructions other than Noop casts impossible. With the recent addition of DW_OP_LLVM_convert this salvaging is now possible, and so can be used to fix the attached bug as well as any cases where SExt instruction results are lost in the debugging metadata. This patch introduces this fix by expanding the salvage debug info method to cover these cases using the new operator. Differential revision: https://reviews.llvm.org/D61184 llvm-svn: 360902
* Reland r360771 "[MergeICmps] Simplify the code."Clement Courbet2019-05-161-145/+150
| | | | | | This revision does not seem to be the culprit. llvm-svn: 360859
* [PredicateInfo] Do not process unreachable operands.Taewook Oh2019-05-151-1/+2
| | | | | | | | | | | | | | Summary: We should excluded unreachable operands from processing as their DFS visitation order is undefined. When `renameUses` function sorts `OpsToRename` (https://fburl.com/d2wubn60), the comparator assumes that the parent block of the operand has a corresponding dominator tree node. This is not the case for unreachable operands and crashes the compiler. Reviewers: dberlin, mgrang, davide Subscribers: efriedma, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61154 llvm-svn: 360796
* [JumpThreading] A bug fix for stale loop info after unfold selectHiroshi Yamauchi2019-05-151-1/+2
| | | | | | | | | | | | | | | | | | | | Summary: The return value of a TryToUnfoldSelect call was not checked, which led to an incorrectly preserved loop info and some crash. The original crash was reported on https://reviews.llvm.org/D59514. Reviewers: davidxl, amehsan Reviewed By: davidxl Subscribers: fhahn, brzycki, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61920 llvm-svn: 360780
* Revert r360771 "[MergeICmps] Simplify the code."Clement Courbet2019-05-151-150/+145
| | | | | | Breaks a bunch of builbdots. llvm-svn: 360776
* [MergeICmps] Fix r360771.Clement Courbet2019-05-151-5/+5
| | | | | | Twine references a StringRef by reference, not value... llvm-svn: 360775
* Revert "[Salvage] Change salvage debug info implementation to use ↵Stephen Tozer2019-05-151-21/+2
| | | | | | | | | DW_OP_LLVM_convert where needed" This reverts r360772 due to build issues. Reverted commit: 17dd4d7403770bd683675e45f5517e0cdb8f9b2b. llvm-svn: 360773
* [Salvage] Change salvage debug info implementation to use DW_OP_LLVM_convert ↵Stephen Tozer2019-05-151-2/+21
| | | | | | | | | | | | | | | | | | where needed Fixes issue: https://bugs.llvm.org/show_bug.cgi?id=40645 Previously, LLVM had no functional way of performing casts inside of a DIExpression(), which made salvaging cast instructions other than Noop casts impossible. With the recent addition of DW_OP_LLVM_convert this salvaging is now possible, and so can be used to fix the attached bug as well as any cases where SExt instruction results are lost in the debugging metadata. This patch introduces this fix by expanding the salvage debug info method to cover these cases using the new operator. Differential revision: https://reviews.llvm.org/D61184 llvm-svn: 360772
* [MergeICmps] Simplify the code.Clement Courbet2019-05-151-145/+150
| | | | | | | | | | | | | | | | | | | Instead of patching the original blocks, we now generate new blocks and delete the old blocks. This results in simpler code with a less twisted control flow (see the change in `entry-block-shuffled.ll`). This will make https://reviews.llvm.org/D60318 simpler by making it more obvious where control flow created and deleted. Reviewers: gchatelet Subscribers: hiraditya, llvm-commits, spatel Tags: #llvm Differential Revision: https://reviews.llvm.org/D61736 llvm-svn: 360771
* [LV] Move getScalarizationOverhead and vector call cost computations to CM. ↵Florian Hahn2019-05-152-62/+61
| | | | | | | | | | | | | | | | | | | | | (NFC) This reduces the number of parameters we need to pass in and they seem a natural fit in LoopVectorizationCostModel. Also simplifies things for D59995. As a follow up refactoring, we could only expose a expose a shouldUseVectorIntrinsic() helper in LoopVectorizationCostModel, instead of calling getVectorCallCost/getVectorIntrinsicCost in InnerLoopVectorizer/VPRecipeBuilder. Reviewers: Ayal, hsaito, dcaballe, rengolin Reviewed By: rengolin Differential Revision: https://reviews.llvm.org/D61638 llvm-svn: 360758
* [IR] Disallow llvm.global_ctors and llvm.global_dtors of the 2-field form in ↵Fangrui Song2019-05-151-27/+7
| | | | | | | | | | | | | | | | | | | | textual format The 3-field form was introduced by D3499 in 2014 and the legacy 2-field form was planned to be removed in LLVM 4.0 For the textual format, this patch migrates the existing 2-field form to use the 3-field form and deletes the compatibility code. test/Verifier/global-ctors-2.ll checks we have a friendly error message. For bitcode, lib/IR/AutoUpgrade UpgradeGlobalVariables will upgrade the 2-field form (add i8* null as the third field). Reviewed By: rnk, dexonsmith Differential Revision: https://reviews.llvm.org/D61547 llvm-svn: 360742
* [NewPM] Port HWASan and Kernel HWASanLeonard Chan2019-05-142-47/+88
| | | | | | | | | | | | | | | Port hardware assisted address sanitizer to new PM following the same guidelines as msan and tsan. Changes: - Separate HWAddressSanitizer into a pass class and a sanitizer class. - Create new PM wrapper pass for the sanitizer class. - Use the getOrINsert pattern for some module level initialization declarations. - Also enable kernel-kwasan in new PM - Update llvm tests and add clang test. Differential Revision: https://reviews.llvm.org/D61709 llvm-svn: 360707
* [LICM] Allow AliasSetMap to contain top-level loops.Florian Hahn2019-05-141-1/+9
| | | | | | | | | | | | | | | When an outer loop gets deleted by a different pass, before LICM visits it, we cannot clean up its sub-loops in AliasSetMap, because at the point we receive the deleteAnalysisLoop callback for the outer loop, the loop object is already invalid and we cannot access its sub-loops any longer. Reviewers: asbirlea, sanjoy, chandlerc Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D61904 llvm-svn: 360704
* [MemorySSA] LoopSimplify preserves MemorySSA only when flag is flipped.Alina Sbirlea2019-05-141-1/+2
| | | | | | | | | | | LoopSimplify can preserve MemorySSA after r360270. But the MemorySSA analysis is retrieved and preserved only when the EnableMSSALoopDependency is set to true. Use the same conditional to mark the pass as preserved, otherwise subsequent passes will get an invalid analysis. Resolves PR41853. llvm-svn: 360697
* Fix a release mode warning introduced in r360694Philip Reames2019-05-141-3/+1
| | | | llvm-svn: 360696
* [IndVars] Extend reasoning about loop invariant exits to non-header blocksPhilip Reames2019-05-141-7/+9
| | | | | | Noticed while glancing through the code for other reasons. The extension is trivial enough, decided to just do it. llvm-svn: 360694
* Support FNeg in SpeculativeExecution passCameron McInally2019-05-141-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D61910 llvm-svn: 360692
* GlobalOpt: do not promote globals used atomically to constants.Tim Northover2019-05-141-1/+6
| | | | | | | | | | Some atomic loads are implemented as cmpxchg (particularly if large or floating), and that usually requires write access to the memory involved or it will segfault. We can still propagate the constant value to users we understand though. llvm-svn: 360662
* [MemorySanitizer] getMMXVectorTy - assert valid element size. NFCI.Simon Pilgrim2019-05-141-0/+2
| | | | | | Fixes scan-build warnings llvm-svn: 360658
* [coroutines] Fix spills of static array allocasGor Nishanov2019-05-131-6/+39
| | | | | | | | | | | | | | | | | | | | | | | Summary: CoroFrame was not considering static array allocas, and was only ever reserving a single element in the coroutine frame. This meant that stores to the non-zero'th element would corrupt later frame data. Store static array allocas as field arrays in the coroutine frame. Added test. Committed by Gor Nishanov on behalf of ben-clayton Reviewers: GorNishanov, modocache Reviewed By: GorNishanov Subscribers: Orlando, capn, EricWF, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61372 llvm-svn: 360636
* [InstCombine] try harder to form rotate (funnel shift) (PR20750)Sanjay Patel2019-05-131-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have a similar match for patterns ending in a truncate. This should be ok for all targets because the default expansion would still likely be better from replacing 2 'and' ops with 1. Attempt to show the logic equivalence in Alive (which doesn't currently have funnel-shift in its vocabulary AFAICT): %shamt = zext i8 %i to i32 %m = and i32 %shamt, 31 %neg = sub i32 0, %shamt %and4 = and i32 %neg, 31 %shl = shl i32 %v, %m %shr = lshr i32 %v, %and4 %or = or i32 %shr, %shl => %a = and i8 %i, 31 %shamt2 = zext i8 %a to i32 %neg2 = sub i32 0, %shamt2 %and4 = and i32 %neg2, 31 %shl = shl i32 %v, %shamt2 %shr = lshr i32 %v, %and4 %or = or i32 %shr, %shl https://rise4fun.com/Alive/V9r llvm-svn: 360605
* Revert "[LSR] Tweak setup cost depth threshold to 10."Amara Emerson2019-05-131-1/+1
| | | | | | Changing the threshold might not be the best long term approach. Revert for now. llvm-svn: 360589
* [ThinLTO] Auto-hide prevailing linkonce_odr only when all copies eligibleTeresa Johnson2019-05-101-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We hit undefined references building with ThinLTO when one source file contained explicit instantiations of a template method (weak_odr) but there were also implicit instantiations in another file (linkonce_odr), and the latter was the prevailing copy. In this case the symbol was marked hidden when the prevailing linkonce_odr copy was promoted to weak_odr. It led to unsats when the resulting shared library was linked with other code that contained a reference (expecting to be resolved due to the explicit instantiation). Add a CanAutoHide flag to the GV summary to allow the thin link to identify when all copies are eligible for auto-hiding (because they were all originally linkonce_odr global unnamed addr), and only do the auto-hide in that case. Most of the changes here are due to plumbing the new flag through the bitcode and llvm assembly, and resulting test changes. I augmented the existing auto-hide test to check for this situation. Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, dexonsmith, arphaman, dang, llvm-commits, steven_wu, wmi Tags: #llvm Differential Revision: https://reviews.llvm.org/D59709 llvm-svn: 360466
* Add InstCombine::visitFNeg(...)Cameron McInally2019-05-102-0/+10
| | | | | | Differential Revision: https://reviews.llvm.org/D61784 llvm-svn: 360461
* [SLP] Refactor VectorizableTree to use unique_ptr.Simon Pilgrim2019-05-101-48/+67
| | | | | | | | | | This patch fixes the TreeEntry dangling pointer issue caused by reallocations of VectorizableTree. Committed on behalf of @vporpo (Vasileios Porpodas) Differential Revision: https://reviews.llvm.org/D61706 llvm-svn: 360456
* [LSR] Tweak setup cost depth threshold to 10.Amara Emerson2019-05-101-1/+1
| | | | | | | | | | The original change introduced a depth limit of 7 which caused a 22% regression in the Swift MapReduceLazyCollection & Ackermann benchmarks. This new threshold still ensures that the original test case doesn't hang. rdar://50359639 llvm-svn: 360444
* [InferAddressSpaces] Enhance the handling of cosntexpr.Michael Liao2019-05-101-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: - Constant expressions may not be added in strict postorder as the forward instruction scan order. Thus, for a constant express (CE0), if its operand (CE1) is used in an previous instruction, they are not in postorder. However, different from `cloneInstructionWithNewAddressSpace`, `cloneConstantExprWithNewAddressSpace` doesn't bookkeep uninferred instructions for later resolving. That results in failure of inferring constant address. - This patch adds the support to infer constant expression operand recursively, since there won't be loop, if that operand is another constant expression. Reviewers: arsenm Subscribers: jholewinski, jvesely, wdng, nhaehnle, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61760 llvm-svn: 360431
* [DebugInfo] Use zero linenos for debug intrinsics when promoting dbg.declareJeremy Morse2019-05-101-9/+26
| | | | | | | | | | | | | | | | | | | | In certain circumstances, optimizations pick line numbers from debug intrinsic instructions as the new location for altered instructions. This is problematic because the line number of a debugging intrinsic is meaningless (it doesn't produce any machine instruction), only the scope information is valid. The result can be the line number of a variable declaration "leaking" into real code from debugging intrinsics, making the line table un-necessarily jumpy, and potentially different with / without variable locations. Fix this by using zero line numbers when promoting dbg.declare intrinsics into dbg.values: this is safe for debug intrinsics as their line numbers are meaningless, and reduces the scope for damage / misleading stepping when optimizations pick locations from the wrong place. Differential Revision: https://reviews.llvm.org/D59272 llvm-svn: 360415
* [CodeGenPrepare] Limit recursion depth for collectBitPartsDavid Stuttard2019-05-091-7/+17
| | | | | | | | | | | | | | | | Summary: Seeing some issues for windows debug pathological cases with collectBitParts recursion (1525 levels of recursion!) Setting the limit to 64 as this should be sufficient - passes all lit cases Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61728 Change-Id: I7f44cdc6c1badf1c2ccbf1b0c4b6afe27ecb39a1 llvm-svn: 360347
* [InstCombine] When turning sext into zext due to known bits, return the new ↵Craig Topper2019-05-081-4/+2
| | | | | | | | | | | | ZExt instead of calling replaceinstuseswith The worklist loop that we're returning back to should be able to do the repacement itself. This is how we normally do replacements. My main motivation was that I observed that we weren't preserving the name of the result when we do this transform. The replacement code in the worklist loop will call takeName as part of the replacement. Differential Revision: https://reviews.llvm.org/D61695 llvm-svn: 360284
* [NewPassManager] Add tuning option: SLPVectorization [NFC].Alina Sbirlea2019-05-082-4/+5
| | | | | | | | | | | | | | Summary: Mirror tuning option from old pass manager in new pass manager. Reviewers: chandlerc Subscribers: mehdi_amini, jlebar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61616 llvm-svn: 360276
* [MemorySSA] Teach LoopSimplify to preserve MemorySSA.Alina Sbirlea2019-05-089-43/+104
| | | | | | | | | | | | | | | Summary: Preserve MemorySSA in LoopSimplify, in the old pass manager, if the analysis is available. Do not preserve it in the new pass manager. Update tests. Subscribers: nemanjai, jlebar, javed.absar, Prazek, kbarton, zzheng, jsji, llvm-commits, george.burgess.iv, chandlerc Tags: #llvm Differential Revision: https://reviews.llvm.org/D60833 llvm-svn: 360270
* [Reassociation] Place moved instructions after landing padsDavid Greene2019-05-081-1/+23
| | | | | | | | | | | | | | | | | Reassociation's NegateValue moved instructions to the beginning of blocks (after PHIs) without checking for exception handling pads. It's possible for reassociation to move something into an exception handling block so we need to make sure we don't move things too early in the block. This change advances the insertion point past any exception handling pads. If the block we want to move into contains a catchswitch, we cannot move into it. In that case just create a new neg as if we had not found an existing neg to move. Differential Revision: https://reviews.llvm.org/D61089 llvm-svn: 360262
* [VPlan] Fix "value never used" static analyzer warning. NFCI.Simon Pilgrim2019-05-081-2/+1
| | | | llvm-svn: 360241
* [SCCP] Fix crash when trying to constant-fold terminators multiple times.Florian Hahn2019-05-081-1/+11
| | | | | | | | | | | | | | If we fold a branch/switch to an unconditional branch to another dead block we replace the branch with unreachable, to avoid attempting to fold the unconditional branch. Reviewers: davide, efriedma, mssimpso, jdoerfert Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D61300 llvm-svn: 360232
* revert r360162 as it breaks most of the buildbotsKostya Serebryany2019-05-072-21/+7
| | | | llvm-svn: 360190
* [InstCombine] Add new combine to add foldingRobert Lougher2019-05-071-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (X | C1) + C2 --> (X | C1) ^ C1 iff (C1 == -C2) I verified the correctness using Alive: https://rise4fun.com/Alive/YNV This transform enables the following transform that already exists in instcombine: (X | Y) ^ Y --> X & ~Y As a result, the full expected transform is: (X | C1) + C2 --> X & ~C1 iff (C1 == -C2) There already exists the transform in the sub case: (X | Y) - Y --> X & ~Y However this does not trigger in the case where Y is constant due to an earlier transform: X - (-C) --> X + C With this new add fold, both the add and sub constant cases are handled. Patch by Chris Dawson. Differential Revision: https://reviews.llvm.org/D61517 llvm-svn: 360185
* [InstCombine] allow sinking fneg operands through an FP min/maxSanjay Patel2019-05-071-5/+5
| | | | | | | | | Fundamentally/generally, we should not have to rely on bailouts/crippling of folds. In this particular case, I think we always recognize the inverted predicate min/max pattern, so there should not be any loss of optimization. Codegen looks better because we are eliminating an fneg. llvm-svn: 360180
* [DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through ↵Orlando Cazalet-Hyams2019-05-072-7/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | loop even after completion Summary: Bug: https://bugs.llvm.org/show_bug.cgi?id=39024 The bug reports that a vectorized loop is stepped through 4 times and each step through the loop seemed to show a different path. I found two problems here: A) An incorrect line number on a preheader block (for.body.preheader) instruction causes a step into the loop before it begins. B) Instructions in the middle block have different line numbers which give the impression of another iteration. In this patch I give all of the middle block instructions the line number of the scalar loop latch terminator branch. This seems to provide the smoothest debugging experience because the vectorized loops will always end on this line before dropping into the scalar loop. To solve problem A I have altered llvm::SplitBlockPredecessors to accommodate loop header blocks. Reviewers: samsonov, vsk, aprantl, probinson, anemet, hfinkel Reviewed By: hfinkel Subscribers: bjope, jmellorcrummey, hfinkel, gbedwell, hiraditya, zzheng, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D60831 llvm-svn: 360162
* Test commit accessOrlando Cazalet-Hyams2019-05-071-2/+2
| | | | llvm-svn: 360125
* [SanitizerCoverage] Use different module ctor names for trace-pc-guard and ↵Fangrui Song2019-05-071-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | inline-8bit-counters Fixes the main issue in PR41693 When both modes are used, two functions are created: `sancov.module_ctor`, `sancov.module_ctor.$LastUnique`, where $LastUnique is the current LastUnique counter that may be different in another module. `sancov.module_ctor.$LastUnique` belongs to the comdat group of the same name (due to the non-null third field of the ctor in llvm.global_ctors). COMDAT group section [ 9] `.group' [sancov.module_ctor] contains 6 sections: [Index] Name [ 10] .text.sancov.module_ctor [ 11] .rela.text.sancov.module_ctor [ 12] .text.sancov.module_ctor.6 [ 13] .rela.text.sancov.module_ctor.6 [ 23] .init_array.2 [ 24] .rela.init_array.2 # 2 problems: # 1) If sancov.module_ctor in this module is discarded, this group # has a relocation to a discarded section. ld.bfd and gold will # error. (Another issue: it is silently accepted by lld) # 2) The comdat group has an unstable name that may be different in # another translation unit. Even if the linker allows the dangling relocation # (with --noinhibit-exec), there will be many undesired .init_array entries COMDAT group section [ 25] `.group' [sancov.module_ctor.6] contains 2 sections: [Index] Name [ 26] .init_array.2 [ 27] .rela.init_array.2 By using different module ctor names, the associated comdat group names will also be different and thus stable across modules. Reviewed By: morehouse, phosek Differential Revision: https://reviews.llvm.org/D61510 llvm-svn: 360107
* Revert "Re-commit r357452: SimplifyCFG SinkCommonCodeFromPredecessors: Also ↵Jordan Rupprecht2019-05-061-15/+14
| | | | | | | | | | sink function calls without used results (PR41259)" This reverts r357452 (git commit 21eb771dcb5c11d7500fa6ad551c97a921997f05). This was causing strange optimization-related test failures on an internal test. Will followup with more details offline. llvm-svn: 360086
* [InstCombine] sink FP negation of operands through selectSanjay Patel2019-05-061-0/+12
| | | | | | | | | | | | | | We don't always get this: Cond ? -X : -Y --> -(Cond ? X : Y) ...even with the legacy IR form of fneg in the case with extra uses, and we miss matching with the newer 'fneg' instruction because we are expecting binops through the rest of the path. Differential Revision: https://reviews.llvm.org/D61604 llvm-svn: 360075
* Pull out repeated CI->getCalledFunction() calls. NFCI.Simon Pilgrim2019-05-061-2/+2
| | | | llvm-svn: 360070
* [InstCombine] reduce code duplication; NFCSanjay Patel2019-05-061-7/+7
| | | | llvm-svn: 360059
* [InstCombine] reduce code duplication; NFCISanjay Patel2019-05-061-22/+19
| | | | llvm-svn: 360051
* [LoadStoreVectorizer] vectorizeStoreChain - ensure we find a store type.Simon Pilgrim2019-05-061-1/+2
| | | | | | | | Properly initialize store type to null then ensure we find a real store type in the chain. Fixes scan-build null dereference warning and makes the code clearer. llvm-svn: 360031
* [SimplifyLibCalls] Simplify bcmp too.Clement Courbet2019-05-061-1/+19
| | | | | | | | | | | | | | Summary: Fixes PR40699. Reviewers: gchatelet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61585 llvm-svn: 360021
* [DebugInfo] GlobalOpt DW_OP_deref_size instead of DW_OP_deref.Markus Lavin2019-05-061-2/+6
| | | | | | | | | | Optimization pass lib/Transforms/IPO/GlobalOpt.cpp needs to insert DW_OP_deref_size instead of DW_OP_deref to be compatible with big-endian targets for same reasons as in D59687. Differential Revision: https://reviews.llvm.org/D60611 llvm-svn: 360013
* [NFC] BasicBlock: refactor changePhiUses() out of replacePhiUsesWith(), use itRoman Lebedev2019-05-052-18/+10
| | | | | | | | | | | | | | | | | | | | | Summary: It is a common thing to loop over every `PHINode` in some `BasicBlock` and change old `BasicBlock` incoming block to a new `BasicBlock` incoming block. `replaceSuccessorsPhiUsesWith()` already had code to do that, it just wasn't a function. So outline it into a new function, and use it. Reviewers: chandlerc, craig.topper, spatel, danielcdh Reviewed By: craig.topper Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61013 llvm-svn: 359996
OpenPOWER on IntegriCloud