summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [InstCombine] dropRedundantMaskingOfLeftShiftInput(): pat. c/d/e with mask ↵Roman Lebedev2019-09-231-3/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (PR42563) Summary: If we have a pattern `(x & (-1 >> maskNbits)) << shiftNbits`, we already know (have a fold) that will drop the `& (-1 >> maskNbits)` mask iff `(shiftNbits-maskNbits) s>= 0` (i.e. `shiftNbits u>= maskNbits`). So even if `(shiftNbits-maskNbits) s< 0`, we can still fold, we will just need to apply a **constant** mask afterwards: ``` Name: c, normal+mask %t0 = lshr i32 -1, C1 %t1 = and i32 %t0, %x %r = shl i32 %t1, C2 => %n0 = shl i32 %x, C2 %n1 = i32 ((-(C2-C1))+32) %n2 = zext i32 %n1 to i64 %n3 = lshr i64 -1, %n2 %n4 = trunc i64 %n3 to i32 %r = and i32 %n0, %n4 ``` https://rise4fun.com/Alive/gslRa Naturally, old `%masked` will have to be one-use. This is not valid for pattern f - where "masking" is done via `ashr`. https://bugs.llvm.org/show_bug.cgi?id=42563 Reviewers: spatel, nikic, xbolva00 Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67725 llvm-svn: 372630
* [InstCombine] dropRedundantMaskingOfLeftShiftInput(): pat. a/b with mask ↵Roman Lebedev2019-09-231-3/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (PR42563) Summary: And this is **finally** the interesting part of that fold! If we have a pattern `(x & (~(-1 << maskNbits))) << shiftNbits`, we already know (have a fold) that will drop the `& (~(-1 << maskNbits))` mask iff `(maskNbits+shiftNbits) u>= bitwidth(x)`. But that is actually ignorant, there's more general fold here: In this pattern, `(maskNbits+shiftNbits)` actually correlates with the number of low bits that will remain in the final value. So even if `(maskNbits+shiftNbits) u< bitwidth(x)`, we can still fold, we will just need to apply a **constant** mask afterwards: ``` Name: a, normal+mask %onebit = shl i32 -1, C1 %mask = xor i32 %onebit, -1 %masked = and i32 %mask, %x %r = shl i32 %masked, C2 => %n0 = shl i32 %x, C2 %n1 = add i32 C1, C2 %n2 = zext i32 %n1 to i64 %n3 = shl i64 -1, %n2 %n4 = xor i64 %n3, -1 %n5 = trunc i64 %n4 to i32 %r = and i32 %n0, %n5 ``` https://rise4fun.com/Alive/F5R Naturally, old `%masked` will have to be one-use. Similar fold exists for patterns c,d,e, will post patch later. https://bugs.llvm.org/show_bug.cgi?id=42563 Reviewers: spatel, nikic, xbolva00 Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67677 llvm-svn: 372629
* [BreakFalseDeps] ignore function with minsize attributeSanjay Patel2019-09-231-0/+11
| | | | | | | | | | | | This came up in the x86-specific: https://bugs.llvm.org/show_bug.cgi?id=43239 ...but it is a general problem for the BreakFalseDeps pass. Dependencies may be broken by adding some other instruction, so that should be avoided if the overall goal is to minimize size. Differential Revision: https://reviews.llvm.org/D67363 llvm-svn: 372628
* [SLP] Fix for PR31847: Assertion failed: (isLoopInvariant(Operands[i], L) && ↵Alexey Bataev2019-09-231-66/+75
| | | | | | | | | | | | | | | | | | | | | "SCEVAddRecExpr operand is not loop-invariant!") Summary: Initially SLP vectorizer replaced all going-to-be-vectorized instructions with Undef values. It may break ScalarEvaluation and may cause a crash. Reworked SLP vectorizer so that it does not replace vectorized instructions by UndefValue anymore. Instead vectorized instructions are marked for deletion inside if BoUpSLP class and deleted upon class destruction. Reviewers: mzolotukhin, mkuper, hfinkel, RKSimon, davide, spatel Subscribers: RKSimon, Gerolf, anemet, hans, majnemer, llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D29641 llvm-svn: 372626
* [InstCombine] foldUnsignedUnderflowCheck(): s/Subtracted/ZeroCmpOp/Roman Lebedev2019-09-231-7/+7
| | | | llvm-svn: 372625
* [AMDGPU][MC] Corrected handling of relocatable expressionsDmitry Preobrazhensky2019-09-231-11/+20
| | | | | | | | | | See bug 43359: https://bugs.llvm.org//show_bug.cgi?id=43359 Reviewers: rampitec Differential Revision: https://reviews.llvm.org/D67829 llvm-svn: 372622
* HexagonLoopIdiomRecognition - silence static analyzer dyn_cast<> null ↵Simon Pilgrim2019-09-231-3/+3
| | | | | | dereference warnings. NFCI. llvm-svn: 372619
* [TextAPI] Add New Supported PlatformsCyndy Ishida2019-09-233-4/+74
| | | | | | | | | | | | | | | | Summary: This patch introduces simulators, as well was the restriced zippered and macCatalyst to supported platforms Reviewers: ributzka, steven_wu Reviewed By: ributzka Subscribers: hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67528 llvm-svn: 372618
* [Hexagon] Bitcast v4i16 to v8i8, unify no-op casts between scalar and HVXKrzysztof Parzyszek2019-09-232-27/+26
| | | | llvm-svn: 372616
* [Alignment][NFC] Migrate Instructions to AlignGuillaume Chatelet2019-09-231-12/+33
| | | | | | | | | | | | | | | | | 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/D67917 llvm-svn: 372613
* [x86] fix assert with horizontal math + broadcast of vector (PR43402)Sanjay Patel2019-09-232-5/+6
| | | | | | https://bugs.llvm.org/show_bug.cgi?id=43402 llvm-svn: 372606
* [ValueTracking] Fix uninitialized variable warnings in matchSelectPattern ↵Simon Pilgrim2019-09-231-5/+6
| | | | | | | | | | const wrapper. NFCI. Static analyzer complains about const_cast uninitialized variables, we should explicitly set these to null. Ideally that const wrapper would go away though....... llvm-svn: 372603
* llvm-undname: Add support for demangling typeinfo namesNico Weber2019-09-231-0/+18
| | | | | | | | | | | | | | typeinfo names aren't symbols but string constant contents stored in compiler-generated typeinfo objects, but llvm-cxxfilt can demangle these for Itanium names. In the MSVC ABI, these are just a '.' followed by a mangled type -- this means they don't start with '?' like all MS-mangled symbols do. Differential Revision: https://reviews.llvm.org/D67851 llvm-svn: 372602
* Cosmetic; don't use the magic constant 35 when HASH is more readable. This ↵Mark Murray2019-09-232-16/+16
| | | | | | | | | | | | | | | | matches other MCK__<THING>_* usage better. Summary: No functional change. This fixes a magic constant in MCK__*_... macros only. Reviewers: ostannard Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67840 llvm-svn: 372599
* Function::BuildLazyArguments() - fix "variable used but never read" analyzer ↵Simon Pilgrim2019-09-231-1/+2
| | | | | | | | warning. NFCI. Simplify the code by separating the masking of the SDC variable from using it. llvm-svn: 372598
* [Alignment][NFC] DataLayout migration to llvm::AlignGuillaume Chatelet2019-09-236-17/+16
| | | | | | | | | | | | | | | | | 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/D67914 llvm-svn: 372596
* [Alignment] Get DataLayout::StackAlignment as AlignGuillaume Chatelet2019-09-233-5/+8
| | | | | | | | | | | | | | | | | | | | Summary: Internally it is needed to know if StackAlignment is set but we can expose it as llvm::Align. 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/D67852 llvm-svn: 372585
* Localizer - fix "variable used but never read" analyzer warning. NFCI.Simon Pilgrim2019-09-231-1/+2
| | | | | | Simplify the code by separating the modification of the Changed variable from returning it. llvm-svn: 372583
* TargetInstrInfo::getStackSlotRange - fix "variable used but never read" ↵Simon Pilgrim2019-09-231-1/+1
| | | | | | | | analyzer warning. NFCI. We don't need to divide the BitSize local variable at all. llvm-svn: 372582
* CriticalAntiDepBreaker - Assert that we've found the bottom of the critical ↵Simon Pilgrim2019-09-231-0/+1
| | | | | | | | path. NFCI. Silences static analyzer null dereference warnings. llvm-svn: 372577
* [FunctionAttrs] Enable nonnull arg propagationDavid Bolvansky2019-09-231-4/+1
| | | | | | Enable flag introduced in rL294998. Security concerns are no longer valid, since function signatures for mentioned libc functions has no nonnull attribute (Clang does not generate them? I see no nonnull attr in LLVM IR for these functions) and since rL372091 we carefully annotate the callsites where we know that size is static, non zero. So let's enable this flag again.. llvm-svn: 372573
* [ARM][MVE] Remove old tail predicatesSam Parker2019-09-232-9/+60
| | | | | | | | | | | Remove any predicate that we replace with a vctp intrinsic, and try to remove their operands too. Also look into the exit block to see if there's any duplicates of the predicates that we've replaced and clone the vctp to be used there instead. Differential Revision: https://reviews.llvm.org/D67709 llvm-svn: 372567
* [AArch64] support neon_sshl and neon_ushl in performIntrinsicCombine.Florian Hahn2019-09-231-0/+25
| | | | | | | | | | | | | | | | Try to generate ushll/sshll for aarch64_neon_ushl/aarch64_neon_sshl, if their first operand is extended and the second operand is a constant Also adds a few tests marked with FIXME, where we can further increase codegen. Reviewers: t.p.northover, samparker, dmgreen, anemet Reviewed By: anemet Differential Revision: https://reviews.llvm.org/D62308 llvm-svn: 372565
* [ARM][LowOverheadLoops] Use subs during revert.Sam Parker2019-09-231-16/+37
| | | | | | | | | | Check whether there are any uses or defs between the LoopDec and LoopEnd. If there's not, then we can use a subs to set the cpsr and skip generating a cmp. Differential Revision: https://reviews.llvm.org/D67801 llvm-svn: 372560
* [Alignment][NFC] Switch DataLayout private members to llvm::AlignGuillaume Chatelet2019-09-231-19/+18
| | | | | | | | | | | | | | | | | 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/D67836 llvm-svn: 372558
* [ARM][LowOverheadLoops] Use tBcc when revertingSam Parker2019-09-231-8/+11
| | | | | | | | | Check the branch target ranges and use a tBcc instead of t2Bcc when we can. Differential Revision: https://reviews.llvm.org/D67796 llvm-svn: 372557
* [MIPS GlobalISel] VarArg argument lowering, select G_VASTART and vacopyPetar Avramovic2019-09-235-6/+80
| | | | | | | | | | | | | | | | CC_Mips doesn't accept vararg functions for O32, so we have to explicitly use CC_Mips_FixedArg. For lowerCall we now properly figure out whether callee function is vararg or not, this has no effect for O32 since we always use CC_Mips_FixedArg. For lower formal arguments we need to copy arguments in register to stack and save pointer to start for argument list into MipsMachineFunction object so that G_VASTART could use it during instruction select. For vacopy we need to copy content from one vreg to another, load and store are used for that purpose. Differential Revision: https://reviews.llvm.org/D67756 llvm-svn: 372555
* [X86] Canonicalize all zeroes vector to RHS in X86DAGToDAGISel::tryVPTESTM.Craig Topper2019-09-231-3/+9
| | | | llvm-svn: 372544
* [X86] Remove SETEQ/SETNE canonicalization code from LowerIntVSETCC_AVX512 to ↵Craig Topper2019-09-232-9/+2
| | | | | | | | | | | | prevent an infinite loop. The attached test case would previous infinite loop after r365711. I'm going to move this to X86ISelDAGToDAG.cpp to get the setcc to match VPTEST in 32-bit mode in a follow up commit. llvm-svn: 372543
* Prefer AVX512 memcpy when applicableDavid Zarzycki2019-09-231-0/+5
| | | | | | | | | | | When AVX512 is available and the preferred vector width is 512-bits or more, we should prefer AVX512 for memcpy(). https://bugs.llvm.org/show_bug.cgi?id=43240 https://reviews.llvm.org/D67874 llvm-svn: 372540
* [X86] Convert to Constant arguments to MMX shift by i32 intrinsics to ↵Craig Topper2019-09-232-5/+8
| | | | | | | | | | | | | | TargetConstant during lowering. This allows us to use timm in the isel table which is more consistent with other intrinsics that take an immediate now. We can't declare the intrinsic as taking an ImmArg because we need to match non-constants to the shift by MMX register instruction which we do by mutating the intrinsic id during lowering. llvm-svn: 372537
* [X86] Remove stale FIXME.Craig Topper2019-09-231-1/+0
| | | | | | | This goes back to when MMX was migrated to intrinsic only. The hack referenced here has been gone for quite a while. llvm-svn: 372536
* [X86][SelectionDAGBuilder] Move the hack for handling MMX shift by i32 ↵Craig Topper2019-09-232-59/+52
| | | | | | | | | | | | | | | | | | | | | | intrinsics into the X86 backend. This intrinsics should be shift by immediate, but gcc allows any i32 scalar and clang needs to match that. So we try to detect the non-constant case and move the data from an integer register to an MMX register. Previously this was done by creating a v2i32 build_vector and bitcast in SelectionDAGBuilder. This had to be done early since v2i32 isn't a legal type. The bitcast+build_vector would be DAG combined to X86ISD::MMX_MOVW2D which isel will turn into a GPR->MMX MOVD. This commit just moves the whole thing to lowering and emits the X86ISD::MMX_MOVW2D directly to avoid the illegal type. The test changes just seem to be due to nodes being linearized in a different order. llvm-svn: 372535
* [X86] Require last argument to LWPINS/LWPVAL builtins to be an ICE. Add ↵Craig Topper2019-09-221-4/+4
| | | | | | | | ImmArg to the llvm intrinsics. Update the isel patterns to use timm instead of imm. llvm-svn: 372534
* [X86] X86DAGToDAGISel::matchBEXTRFromAndImm(): if can't use BEXTR, fallback ↵Roman Lebedev2019-09-221-12/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to BZHI is profitable (PR43381) Summary: PR43381 notes that while we are good at matching `(X >> C1) & C2` as BEXTR/BEXTRI, we only do that if we either have BEXTRI (TBM), or if BEXTR is marked as being fast (`-mattr=+fast-bextr`). In all other cases we don't match. But that is mainly only true for AMD CPU's. However, for all the CPU's for which we have sched models, the BZHI is always fast (or the sched models are all bad.) So if we decide that it's unprofitable to emit BEXTR/BEXTRI, we should consider falling-back to BZHI if it is available, and follow-up with the shift. While it's really tempting to do something because it's cool it is wise to first think whether it actually makes sense to do. We shouldn't just use BZHI because we can, but only it it is beneficial. In particular, it isn't really worth it if the input is a register, mask is small, or we can fold a load. But it is worth it if the mask does not fit into 32-bits. (careful, i don't know much about intel cpu's, my choice of `-mcpu` may be bad here) Thus we manage to fold a load: https://godbolt.org/z/Er0OQz Or if we'd end up using BZHI anyways because the mask is large: https://godbolt.org/z/dBJ_5h But this isn'r actually profitable in general case, e.g. here we'd increase microop count (the register renaming is free, mca does not model that there it seems) https://godbolt.org/z/k6wFoz Likewise, not worth it if we just get load folding: https://godbolt.org/z/1M1deG https://bugs.llvm.org/show_bug.cgi?id=43381 Reviewers: RKSimon, craig.topper, davezarzycki, spatel Reviewed By: craig.topper, davezarzycki Subscribers: andreadb, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67875 llvm-svn: 372532
* Verifier - silence static analyzer dyn_cast<VectorType> null dereference ↵Simon Pilgrim2019-09-221-4/+4
| | | | | | | | warnings. NFCI. The static analyzer is warning about potential null dereferences, but we should be able to use cast<VectorType> directly and if not assert will fire for us. llvm-svn: 372529
* [AMDGPU] isSDNodeAlwaysUniform - silence static analyzer ↵Simon Pilgrim2019-09-221-3/+2
| | | | | | | | dyn_cast<LoadSDNode> null dereference warning. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<LoadSDNode> directly and if not assert will fire for us. llvm-svn: 372528
* [X86] Fix some VCVTPS2PH isel patterns where 'i32' was used instead of 'timm'Craig Topper2019-09-222-14/+14
| | | | | | | This seems to have completed omitted any check for the opcode of the operand in the isel table. llvm-svn: 372526
* [X86][TableGen] Allow timm to appear in output patterns. Use it to remove ↵Craig Topper2019-09-223-119/+119
| | | | | | | | | | | | | | ConvertToTarget opcodes from the X86 isel table. We're now using a lot more TargetConstant nodes in SelectionDAG. But we were still telling isel to convert some of them to TargetConstants even though they already are. This is because isel emits a conversion anytime the output pattern has a an 'imm'. I guess for patterns in instructions we take the 'timm' from the 'set' pattern, but for Pat patterns with explcicit output we previously had to say 'imm' since 'timm' wasn't allowed in outputs. llvm-svn: 372525
* [X86] Update commutable EVEX vcmp patterns to use timm instead of imm.Craig Topper2019-09-221-6/+6
| | | | | | | We need to match TargetConstant, not Constant. This was broken in r372338, but we lacked test coverage. llvm-svn: 372523
* [SelectionDAG] computeKnownBits/ComputeNumSignBits - cleanup ↵Simon Pilgrim2019-09-221-7/+6
| | | | | | | | demanded/unknown paths. NFCI. Merge the calls, just adjust the demandedelts if we have a valid extract_subvector constant index, else demand all elts. llvm-svn: 372521
* [XRay] Silence static analyzer dyn_cast<BufferExtents> null dereference ↵Simon Pilgrim2019-09-221-1/+1
| | | | | | warning. NFCI. llvm-svn: 372520
* [LSR] Silence static analyzer null dereference warnings with assertions. NFCI.Simon Pilgrim2019-09-221-0/+2
| | | | | | Add assertions to make it clear that GenerateIVChain / NarrowSearchSpaceByPickingWinnerRegs should succeed in finding non-null values llvm-svn: 372518
* ConstantHoisting - Silence static analyzer dyn_cast<PointerType> null ↵Simon Pilgrim2019-09-221-1/+1
| | | | | | dereference warning. NFCI. llvm-svn: 372517
* [Cost][X86] Add more missing vector truncation costsSimon Pilgrim2019-09-221-0/+6
| | | | | | The AVX512 cases still need some work to correct recognise the PMOV truncation cases. llvm-svn: 372514
* [InstCombine] allow icmp+binop folds before min/max bailout (PR43310)Sanjay Patel2019-09-222-3/+4
| | | | | | | | | This has the potential to uncover missed analysis/folds as shown in the min/max code comment/test, but fewer restrictions on icmp folds should be better in general to solve cases like: https://bugs.llvm.org/show_bug.cgi?id=43310 llvm-svn: 372510
* Fix uninitialized variable warning. NFCI.Simon Pilgrim2019-09-221-1/+1
| | | | llvm-svn: 372508
* [AArch64] AArch64StackTagging - Silence static analyzer dyn_cast<> null ↵Simon Pilgrim2019-09-221-1/+1
| | | | | | | | dereference warning. NFCI. The static analyzer is warning about potential null dereferences, but we should be able to use cast<> directly and if not assert will fire for us. llvm-svn: 372507
* [NVPTX] NVPTXLowerAggrCopies - Silence static analyzer dyn_cast<StoreInst> ↵Simon Pilgrim2019-09-221-1/+1
| | | | | | null dereference warning. NFCI. llvm-svn: 372504
* [Lanai] LanaiAsmParser - Silence static analyzer dyn_cast null dereference ↵Simon Pilgrim2019-09-221-8/+9
| | | | | | | | warnings. NFCI. We were already doing this dyn_cast && isa<> && cast<> pattern for some add*Operands methods, just do this more consistently to stop clang static analyzer warning so much. llvm-svn: 372503
OpenPOWER on IntegriCloud