summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [Alignment][NFC] Convert StoreInst to MaybeAlignGuillaume Chatelet2019-10-227-37/+32
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69303 llvm-svn: 375499
* [Alignment][NFC] Convert LoadInst to MaybeAlignGuillaume Chatelet2019-10-229-30/+29
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69302 llvm-svn: 375498
* [PowerPC] Turn on CR-Logical reducer passNemanja Ivanovic2019-10-222-5/+6
| | | | | | | | | | | | | | This re-commits r375152 which was pulled in r375233 because it broke the EXPENSIVE_CHECKS bot on Windows. The reason for the failure was a bug in the pass that the commit turned on by default. This patch fixes that bug and turns the pass back on. This patch has been verified on the buildbot that originally failed thanks to Simon Pilgrim. Differential revision: https://reviews.llvm.org/D52431 llvm-svn: 375497
* [Alignment][NFC] Use MaybeAlign in AttrBuilderGuillaume Chatelet2019-10-223-28/+37
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69300 llvm-svn: 375496
* [Alignment][NFC] Attributes use Align/MaybeAlignGuillaume Chatelet2019-10-223-33/+28
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69278 llvm-svn: 375495
* [ThinLTO] Don't internalize during promotionEugene Leviant2019-10-221-0/+1
| | | | | | Differential revision: https://reviews.llvm.org/D69107 llvm-svn: 375493
* [LLVMDebugInfoPDB] - Use cantFail() instead of assert().George Rimar2019-10-221-12/+13
| | | | | | | | | | | | | | | | Currently injected-sources-native.test fails with "Expected<T> value was in success state. (Note: Expected<T> values in success mode must still be checked prior to being destroyed)" when llvm is compiled with LLVM_ENABLE_ABI_BREAKING_CHECKS in Release. The problem is that getStringForID returns Expected<StringRef> and Expected value must always be checked, even if it is in success state. Checking with assert only helps in Debug and is wrong. Differential revision: https://reviews.llvm.org/D69251 llvm-svn: 375492
* [X86][BMI] Pull out schedule classes from bmi_andn<> and bmi_bls<>Simon Pilgrim2019-10-212-14/+15
| | | | | | Stop hardwiring classes llvm-svn: 375470
* [X86][SSE] Add OR(EXTRACTELT(X,0),OR(EXTRACTELT(X,1))) -> MOVMSK+CMP ↵Simon Pilgrim2019-10-211-0/+18
| | | | | | reduction combine llvm-svn: 375463
* AMDGPU/GlobalISel: Legalize fast unsafe FDIVAustin Kerbow2019-10-212-6/+90
| | | | | | | | | | | | | | Reviewers: arsenm Reviewed By: arsenm Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, rovka, dstuttard, tpr, t-tye, hiraditya, Petar.Avramovic, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69231 llvm-svn: 375460
* AMDGPU: Select basic interp directly from intrinsicsMatt Arsenault2019-10-215-57/+29
| | | | llvm-svn: 375457
* [CVP] No-wrap deduction for `shl`Roman Lebedev2019-10-211-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the last `OverflowingBinaryOperator` for which we don't deduce flags. D69217 taught `ConstantRange::makeGuaranteedNoWrapRegion()` about it. The effect is better than of the `mul` patch (D69203): | statistic | old | new | delta | % change | | correlated-value-propagation.NumAddNUW | 7145 | 7144 | -1 | -0.0140% | | correlated-value-propagation.NumAddNW | 12126 | 12125 | -1 | -0.0082% | | correlated-value-propagation.NumAnd | 443 | 446 | 3 | 0.6772% | | correlated-value-propagation.NumNSW | 5986 | 7158 | 1172 | 19.5790% | | correlated-value-propagation.NumNUW | 10512 | 13304 | 2792 | 26.5601% | | correlated-value-propagation.NumNW | 16498 | 20462 | 3964 | 24.0272% | | correlated-value-propagation.NumShlNSW | 0 | 1172 | 1172 | | | correlated-value-propagation.NumShlNUW | 0 | 2793 | 2793 | | | correlated-value-propagation.NumShlNW | 0 | 3965 | 3965 | | | instcount.NumAShrInst | 13824 | 13790 | -34 | -0.2459% | | instcount.NumAddInst | 277584 | 277586 | 2 | 0.0007% | | instcount.NumAndInst | 66061 | 66056 | -5 | -0.0076% | | instcount.NumBrInst | 709153 | 709147 | -6 | -0.0008% | | instcount.NumICmpInst | 483709 | 483708 | -1 | -0.0002% | | instcount.NumSExtInst | 79497 | 79496 | -1 | -0.0013% | | instcount.NumShlInst | 40691 | 40654 | -37 | -0.0909% | | instcount.NumSubInst | 61997 | 61996 | -1 | -0.0016% | | instcount.NumZExtInst | 68208 | 68211 | 3 | 0.0044% | | instcount.TotalBlocks | 843916 | 843910 | -6 | -0.0007% | | instcount.TotalInsts | 7387528 | 7387448 | -80 | -0.0011% | Reviewers: nikic, reames, sanjoy, timshen Reviewed By: nikic Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69277 llvm-svn: 375455
* [GISel][CombinerHelper] Add a combine turning shuffle_vector into concat_vectorsQuentin Colombet2019-10-212-0/+89
| | | | | | | | | | Teach the CombinerHelper how to turn shuffle_vectors, that concatenate vectors, into concat_vectors and add this combine to the AArch64 pre-legalizer combiner. Differential Revision: https://reviews.llvm.org/D69149 llvm-svn: 375452
* AMDGPU: Use CopyToReg for interp intrinsic loweringMatt Arsenault2019-10-211-16/+17
| | | | | | | This doesn't use the default value, so doesn't benefit from the hack to help optimize it. llvm-svn: 375450
* AMDGPU: Erase redundant redefs of m0 in SIFoldOperandsMatt Arsenault2019-10-211-0/+21
| | | | | | | | | | | | | Only handle simple inter-block redefs of m0 to the same value. This avoids interference from redefs of m0 in SILoadStoreOptimzer. I was initially teaching that pass to ignore redefs of m0, but having them not exist beforehand is much simpler. This is in preparation for deleting the current special m0 handling in SIFixSGPRCopies to allow the register coalescer to handle the difficult cases. llvm-svn: 375449
* AMDGPU: Stop adding m0 implicit def to SGPR spillsMatt Arsenault2019-10-211-13/+2
| | | | | | | | r375293 removed the SGPR spilling with scalar stores path, so this is no longer necessary. This also always had the defect of adding the def even when this path wasn't in use. llvm-svn: 375448
* AMDGPU: Slightly restructure m0 init codeMatt Arsenault2019-10-211-13/+15
| | | | | | | This will allow using another operation to produce the glue in a future change. llvm-svn: 375447
* [AMDGPU] Select AGPR in PHI operand legalizationStanislav Mekhanoshin2019-10-211-0/+4
| | | | | | | | | | | | | | If a PHI defines AGPR legalize its operands to AGPR. At the moment we can get an AGPR PHI with VGPR operands. I am not aware of any problems as it seems to be handled gracefully in RA, but this is not right anyway. It also slightly decreases VGPR pressure in some cases because we do not have to a copy via VGPR. Differential Revision: https://reviews.llvm.org/D69206 llvm-svn: 375446
* [X86] Rename matchBitOpReduction to matchScalarReduction. NFCI.Simon Pilgrim2019-10-211-4/+4
| | | | | | This doesn't need to be just for bitops, but the ops do need to be fully associative. llvm-svn: 375445
* Reverted r375425 as it broke some buildbots.Sander de Smalen2019-10-217-81/+8
| | | | llvm-svn: 375444
* Prune Pass.h include from DataLayout.h. NFCIBjorn Pettersson2019-10-211-0/+1
| | | | | | | | | | | | | | | | | | | Summary: Reduce include dependencies by no longer including Pass.h from DataLayout.h. That include seemed irrelevant to DataLayout, as well as being irrelevant to several users of DataLayout. Reviewers: rnk Reviewed By: rnk Subscribers: mehdi_amini, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69261 llvm-svn: 375436
* SystemZISelLowering - supportedAddressingMode - silence static analyzer ↵Simon Pilgrim2019-10-211-1/+1
| | | | | | | | dyn_cast<> null dereference warning. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<> directly and if not assert will fire for us. llvm-svn: 375430
* GVNHoist - silence static analyzer dyn_cast<> null dereference warning in ↵Simon Pilgrim2019-10-211-1/+1
| | | | | | | | hasEHOrLoadsOnPath call. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<> directly and if not assert will fire for us. llvm-svn: 375429
* GuardWidening - silence static analyzer null dereference warning with ↵Simon Pilgrim2019-10-211-1/+1
| | | | | | assertion. NFCI. llvm-svn: 375428
* CrossDSOCFI - silence static analyzer dyn_cast<> null dereference warning. NFCI.Simon Pilgrim2019-10-211-1/+1
| | | | | | The static analyzer is warning about a potential null dereference, but we should be able to use cast<> directly and if not assert will fire for us. llvm-svn: 375427
* IndVarSimplify - silence static analyzer dyn_cast<> null dereference ↵Simon Pilgrim2019-10-211-2/+2
| | | | | | | | warning. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<> directly and if not assert will fire for us. llvm-svn: 375426
* [AArch64][DebugInfo] Do not recompute CalleeSavedStackSize (Take 2)Sander de Smalen2019-10-217-8/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit message from D66935: This patch fixes a bug exposed by D65653 where a subsequent invocation of `determineCalleeSaves` ends up with a different size for the callee save area, leading to different frame-offsets in debug information. In the invocation by PEI, `determineCalleeSaves` tries to determine whether it needs to spill an extra callee-saved register to get an emergency spill slot. To do this, it calls 'estimateStackSize' and manually adds the size of the callee-saves to this. PEI then allocates the spill objects for the callee saves and the remaining frame layout is calculated accordingly. A second invocation in LiveDebugValues causes estimateStackSize to return the size of the stack frame including the callee-saves. Given that the size of the callee-saves is added to this, these callee-saves are counted twice, which leads `determineCalleeSaves` to believe the stack has become big enough to require spilling an extra callee-save as emergency spillslot. It then updates CalleeSavedStackSize with a larger value. Since CalleeSavedStackSize is used in the calculation of the frame offset in getFrameIndexReference, this leads to incorrect offsets for variables/locals when this information is recalculated after PEI. This patch fixes the lldb unit tests in `functionalities/thread/concurrent_events/*` Changes after D66935: Ensures AArch64FunctionInfo::getCalleeSavedStackSize does not return the uninitialized CalleeSavedStackSize when running `llc` on a specific pass where the MIR code has already been expected to have gone through PEI. Instead, getCalleeSavedStackSize (when passed the MachineFrameInfo) will try to recalculate the CalleeSavedStackSize from the CalleeSavedInfo. In debug mode, the compiler will assert the recalculated size equals the cached size as calculated through a call to determineCalleeSaves. This fixes two tests: test/DebugInfo/AArch64/asan-stack-vars.mir test/DebugInfo/AArch64/compiler-gen-bbs-livedebugvalues.mir that otherwise fail when compiled using msan. Reviewed By: omjavaid, efriedma Tags: #llvm Differential Revision: https://reviews.llvm.org/D68783 llvm-svn: 375425
* [NFC] Cleanup with variable name IsPPC64 & IsDarwinXiangling Liao2019-10-211-20/+18
| | | | | | | | Clean up PPCAsmPrinter with IsPPC64 and IsDarwin. Differential Revision: https://reviews.llvm.org/D69259 llvm-svn: 375420
* [Alignment][NFC] Finish transition for `Loads`Guillaume Chatelet2019-10-2110-72/+72
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, asbirlea, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69253 llvm-svn: 375419
* [Alignment][NFC] Instructions::getLoadStoreAlignmentGuillaume Chatelet2019-10-212-41/+47
| | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69256 llvm-svn: 375416
* [ARM] Extra qdadd patternsDavid Green2019-10-212-0/+8
| | | | | | | | | This adds some new qdadd patterns to go along with the other recently added qadd's. Differential Revision: https://reviews.llvm.org/D68999 llvm-svn: 375414
* [ARM] Add qadd lowering from a sadd_satDavid Green2019-10-214-4/+19
| | | | | | | | | | | | This lowers a sadd_sat to a qadd by treating it as legal. Also adds qsub at the same time. The qadd instruction sets the q flag, but we already have many cases where we do not model this in llvm. Differential Revision: https://reviews.llvm.org/D68976 llvm-svn: 375411
* [Alignment][NFC] TargetCallingConv::setByValAlignGuillaume Chatelet2019-10-213-4/+4
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69248 llvm-svn: 375410
* [llvm/Object] - Make ELFObjectFile::getRelocatedSection return ↵George Rimar2019-10-214-6/+35
| | | | | | | | | | | | | Expected<section_iterator> It returns just a section_iterator currently and have a report_fatal_error call inside. This change adds a way to return errors and handle them on caller sides. The patch also changes/improves current users and adds test cases. Differential revision: https://reviews.llvm.org/D69167 llvm-svn: 375408
* [Alignment][NFC] TargetCallingConv::setOrigAlign and ↵Guillaume Chatelet2019-10-219-31/+26
| | | | | | | | | | | | | | | | | | | TargetLowering::getABIAlignmentForCallingConv Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: sdardis, hiraditya, jrtc27, atanasyan, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69243 llvm-svn: 375407
* [MemCpyOpt] Fixing Incorrect Code Motion while Handling Aggregate Type ValuesSam Elliott2019-10-211-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When MemCpyOpt is handling aggregate type values, if an instruction (let's call it P) between the targeting load (L) and store (S) clobbers the source pointer of L, it will try to hoist S before P. This process will also hoist S's data dependency instructions. However, the current implementation has a bug that if one of S's dependency instructions is //also// a user of P, MemCpyOpt will not prevent it from being hoisted above P and cause a use-before-define error. For example, in the newly added test file (i.e. `aggregate-type-crash.ll`), it will try to hoist both `store %my_struct %1, %my_struct* %3` and its dependent, `%3 = bitcast i8* %2 to %my_struct*`, above `%2 = call i8* @my_malloc(%my_struct* %0)`. Creating the following BB: ``` entry: %1 = bitcast i8* %4 to %my_struct* %2 = bitcast %my_struct* %1 to i8* %3 = bitcast %my_struct* %0 to i8* call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 4 %2, i8* align 4 %3, i64 8, i1 false) %4 = call i8* @my_malloc(%my_struct* %0) ret void ``` Where there is a use-before-define error between `%1` and `%4`. Update: The compiler for the Pony Programming Language [also encounter the same bug](https://github.com/ponylang/ponyc/issues/3140) Patch by Min-Yih Hsu (myhsu) Reviewers: eugenis, pcc, dblaikie, dneilson, t.p.northover, lattner Reviewed By: eugenis Subscribers: lenary, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66060 llvm-svn: 375403
* [ARM] Lower sadd_sat to qadd8 and qadd16David Green2019-10-214-1/+87
| | | | | | | | | | | | | | Lower the target independent signed saturating intrinsics to qadd8 and qadd16. This custom lowers them from a sadd_sat, catching the node early before it is promoted. It also adds a QADD8b and QADD16b node to mean the bottom "lane" of a qadd8/qadd16, so that we can call demand bits on it to show that it does not use the upper bits. Also handles QSUB8 and QSUB16. Differential Revision: https://reviews.llvm.org/D68974 llvm-svn: 375402
* Use Align for TFL::TransientStackAlignmentGuillaume Chatelet2019-10-2113-14/+14
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: arsenm, dschuff, jyknight, sdardis, jvesely, nhaehnle, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, jrtc27, atanasyan, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69216 llvm-svn: 375398
* [NFC][InstCombine] Fixup commentsRoman Lebedev2019-10-211-2/+2
| | | | | | As noted in post-commit review of rL375378375378. llvm-svn: 375397
* [CVP] Deduce no-wrap on `mul`Roman Lebedev2019-10-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: `ConstantRange::makeGuaranteedNoWrapRegion()` knows how to deal with `mul` since rL335646, there is exhaustive test coverage. This is already used by CVP's `processOverflowIntrinsic()`, and by SCEV's `StrengthenNoWrapFlags()` That being said, currently, this doesn't help much in the end: | statistic | old | new | delta | percentage | | correlated-value-propagation.NumMulNSW | 4 | 275 | 271 | 6775.00% | | correlated-value-propagation.NumMulNUW | 4 | 1323 | 1319 | 32975.00% | | correlated-value-propagation.NumMulNW | 8 | 1598 | 1590 | 19875.00% | | correlated-value-propagation.NumNSW | 5715 | 5986 | 271 | 4.74% | | correlated-value-propagation.NumNUW | 9193 | 10512 | 1319 | 14.35% | | correlated-value-propagation.NumNW | 14908 | 16498 | 1590 | 10.67% | | instcount.NumAddInst | 275871 | 275869 | -2 | 0.00% | | instcount.NumBrInst | 708234 | 708232 | -2 | 0.00% | | instcount.NumMulInst | 43812 | 43810 | -2 | 0.00% | | instcount.NumPHIInst | 316786 | 316784 | -2 | 0.00% | | instcount.NumTruncInst | 62165 | 62167 | 2 | 0.00% | | instcount.NumUDivInst | 2528 | 2526 | -2 | -0.08% | | instcount.TotalBlocks | 842995 | 842993 | -2 | 0.00% | | instcount.TotalInsts | 7376486 | 7376478 | -8 | 0.00% | (^ test-suite plain, tests still pass) Reviewers: nikic, reames, luqmana, sanjoy, timshen Reviewed By: reames Subscribers: hiraditya, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69203 llvm-svn: 375396
* [InstCombine] Allow values with multiple users in SimplifyDemandedVectorEltsPiotr Sobczak2019-10-213-27/+115
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Allow for ignoring the check for a single use in SimplifyDemandedVectorElts to be able to simplify operands if DemandedElts is known to contain the union of elements used by all users. It is a responsibility of a caller of SimplifyDemandedVectorElts to supply correct DemandedElts. Simplify a series of extractelement instructions if only a subset of elements is used. Reviewers: reames, arsenm, majnemer, nhaehnle Reviewed By: nhaehnle Subscribers: wdng, jvesely, nhaehnle, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67345 llvm-svn: 375395
* [IR] Fix mayReadFromMemory() for writeonly callsYevgeny Rouban2019-10-211-1/+1
| | | | | | | | | | | | | | Current implementation of Instruction::mayReadFromMemory() returns !doesNotAccessMemory() which is !ReadNone. This does not take into account that the writeonly attribute also indicates that the call does not read from memory. The patch changes the predicate to !doesNotReadMemory() that reflects the intended behavior. Differential Revision: https://reviews.llvm.org/D69086 llvm-svn: 375389
* [BPF] fix indirect call assembly codeYonghong Song2019-10-211-1/+1
| | | | | | | | | | | | | Currently, for indirect call, the assembly code printed out as callx <imm> This is not right, it should be callx <reg> Fixed the issue with proper format. Differential Revision: https://reviews.llvm.org/D69229 llvm-svn: 375386
* [Attributor][FIX] Silence sign-compare warningJohannes Doerfert2019-10-211-1/+1
| | | | llvm-svn: 375384
* [Attributor] Teach AANoCapture to use information in-flight more aggressivelyJohannes Doerfert2019-10-211-8/+63
| | | | | | | | | AAReturnedValues, AAMemoryBehavior, and AANoUnwind, can provide information that helps during the tracking or even justifies no-capture. We now use this information and enable no-capture in some test cases designed a long while a ago for these cases. llvm-svn: 375382
* [X86] Check Subtarget.hasSSE3() before calling shouldUseHorizontalOp and ↵Craig Topper2019-10-201-1/+1
| | | | | | | | | | emitting X86ISD::FHADD in LowerUINT_TO_FP_i64. This was a regression from r375341. Fixes PR43729. llvm-svn: 375381
* [IndVars] Add a todo to reflect a further oppurtunity identified in D69009Philip Reames2019-10-201-0/+7
| | | | | | Nikita pointed out an oppurtunity, might as well document it in the code. llvm-svn: 375380
* [IndVars] Eliminate loop exits with equivalent exit countsPhilip Reames2019-10-201-4/+28
| | | | | | | | | | | | We can end up with two loop exits whose exit counts are equivalent, but whose textual representation is different and non-obvious. For the sub-case where we have a series of exits which dominate one another (common), eliminate any exits which would iterate *after* a previous exit on the exiting iteration. As noted in the TODO being removed, I'd always thought this was a good idea, but I've now seen this in a real workload as well. Interestingly, in review, Nikita pointed out there's let another oppurtunity to leverage SCEV's reasoning. If we kept track of the min of dominanting exits so far, we could discharge exits with EC >= MDE. This is less powerful than the existing transform (since later exits aren't considered), but potentially more powerful for any case where SCEV can prove a >= b, but neither a == b or a > b. I don't have an example to illustrate that oppurtunity, but won't be suprised if we find one and return to handle that case as well. Differential Revision: https://reviews.llvm.org/D69009 llvm-svn: 375379
* [InstCombine] conditional sign-extend of high-bit-extract: 'or' pattern.Roman Lebedev2019-10-203-18/+23
| | | | | | | | | | | | | | In this pattern, all the "magic" bits that we'd `add` are all high sign bits, and in the value we'd be adding to they are all unset, not unexpectedly, so we can have an `or` there: https://rise4fun.com/Alive/ups It is possible that `haveNoCommonBitsSet()` should be taught about this pattern so that we never have an `add` variant, but the reasoning would need to be recursive (because of that `select`), so i'm not really sure that would be worth it just yet. llvm-svn: 375378
* Reverted r375254 as it has broken some build bots for a long time.Vladimir Vereschaka2019-10-206-192/+18
| | | | llvm-svn: 375375
OpenPOWER on IntegriCloud