aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Analysis/ValueTracking.cpp
AgeCommit message (Collapse)AuthorFilesLines
2020-07-30[ValueTracking] Add basic computeKnownBits support for llvm.abs intrinsicCraig Topper1-0/+11
This includes basic support for computeKnownBits on abs. I've left FIXMEs for more complicated things we could do. Differential Revision: https://reviews.llvm.org/D84963
2020-07-26[ValueTracking] Instruction::isBinaryOp should be used for constexprsJuneyoung Lee1-1/+1
This is a simple patch that makes canCreateUndefOrPoison use Instruction::isBinaryOp because BinaryOperator inherits Instruction. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D84596
2020-07-24[Mem2Reg] Teach promote to register about droppable instructionsJohannes Doerfert1-5/+20
This is the first of two patches to address PR46753. We basically allow mem2reg to promote allocas that are used in doppable instructions, for now that means `llvm.assume`. The uses of the alloca (or a bitcast or zero offset GEP from there) are replaced by `undef` in the droppable instructions. Reviewed By: Tyker Differential Revision: https://reviews.llvm.org/D83976
2020-07-24[ValueTracking] Check for ConstantExpr before using recursive helpers.Florian Hahn1-2/+2
Make sure we do not call constainsConstantExpression/containsUndefElement on ConstantExpression, which is not supported. In particular, containsUndefElement/constainsConstantExpression are only supported on constants which are supported by getAggregateElement. Unfortunately there's no convenient way to check if a constant supports getAggregateElement, so just check for non-constantexpressions with vector type. Other users of those functions do so too. Reviewers: spatel, nikic, craig.topper, lebedev.ri, jdoerfert, aqjune Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D84512
2020-07-22[SVE] Remove calls to VectorType::getNumElements from AnalysisChristopher Tetreault1-6/+8
Reviewers: efriedma, fpetrogalli, c-rhodes, asbirlea, RKSimon Reviewed By: RKSimon Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81504
2020-07-22[ValueTracking] Fix incorrect handling of canCreateUndefOrPoisonJuneyoung Lee1-4/+1
.. in isGuaranteedNotToBeUndefOrPoison. This caused early exit of isGuaranteedNotToBeUndefOrPoison, making it return imprecise result. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D84251
2020-07-20[ValueTracking] Let isGuaranteedNotToBeUndefOrPoison use canCreateUndefOrPoisonJuneyoung Lee1-37/+18
This patch adds support more operations. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D83926
2020-07-20[ValueTracking] Add canCreateUndefOrPoison & let canCreatePoison use OperatorJuneyoung Lee1-25/+45
This patch - adds `canCreateUndefOrPoison` - refactors `canCreatePoison` so it can deal with constantexprs `canCreateUndefOrPoison` will be used at D83926. Reviewed By: nikic, jdoerfert Differential Revision: https://reviews.llvm.org/D84007
2020-07-17[ValueTracking] Let isGuaranteedNotToBeUndefOrPoison consider noundefJuneyoung Lee1-0/+6
This patch adds support for noundef arguments. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D83752
2020-07-16IR: Rename Argument::hasPassPointeeByValueAttr to prepare for byrefMatt Arsenault1-1/+1
When the byref attribute is added, there will need to be two similar functions for the existing cases which have an associate value copy, and byref which does not. Most, but not all of the existing uses will use the existing version. The associated size function added by D82679 also needs to contextually differ, and will help eliminate a few places still relying on pointee element types.
2020-07-16ValueTracking: Fix isKnownNonZero for non-0 null pointers for byvalMatt Arsenault1-4/+9
The IR doesn't have a proper concept of invalid pointers, and "null" constants are just all zeros (though it really needs one). I think it's not possible to break this for AMDGPU due to the copy semantics of byval. If you have an original stack object at 0, the byval copy will be placed above it so I don't think it's really possible to hit a 0 address.
2020-07-14[ValueTracking] fix library to intrinsic mapping to respect 'nobuiltin' ↵Sanjay Patel1-12/+5
attribute This is another problem raised in: http://bugs.llvm.org/PR46627
2020-07-14[ValueTracking] fix miscompile in maxnum case of ↵Sanjay Patel1-7/+22
cannotBeOrderedLessThanZeroImpl (PR46627) A miscompile with -0.0 is shown in: http://bugs.llvm.org/PR46627 This is because maxnum(-0.0, +0.0) does not specify a fixed result: http://llvm.org/docs/LangRef.html#llvm-maxnum-intrinsic So we need to tighten the constraints for when it is ok to say the result of maxnum is positive (including +0.0). Differential Revision: https://reviews.llvm.org/D83601
2020-07-01[Alignment][NFC] Transition and simplify calls to DL::getABITypeAlignmentGuillaume Chatelet1-10/+2
This 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 Differential Revision: https://reviews.llvm.org/D82956
2020-06-27[ValueTracking] Use a switch statement (NFC)Nikita Popov1-6/+11
2020-06-25[IR] GetUnderlyingObject(), stripPointerCastsAndOffsets(): don't crash on ↵Roman Lebedev1-0/+2
`bitcast <1 x i8*> to i8*` I'm not sure how to write standalone tests for each of two changes here. If either one of these two fixes is missing, the test fill crash.
2020-06-21[ValueTracking, BasicAA] Don't simplify instructionsNikita Popov1-12/+7
GetUnderlyingObject() (and by required symmetry DecomposeGEPExpression()) will call SimplifyInstruction() on the passed value if other checks fail. This simplification is very expensive, but has little effect in practice. This patch removes the SimplifyInstruction call(), and replaces it with a check for single-argument phis (which can occur in canonical IR in LCSSA form), which is the only useful simplification case I was able to identify. At O3 the geomean CTMark improvement is -1.7%. The largest improvement is SPASS with ThinLTO at -6%. In test-suite, I see only two tests with a hash difference and no code size difference (PAQ8p, Ptrdist), which indicates that the simplification only ends up being useful very rarely. (I would have liked to figure out which simplification is responsible here, but wasn't able to spot it looking at transformation logs.) The AMDGPU test case that is update was using two selects with undef condition, in which case GetUnderlyingObject will return the first select operand as the underlying object. This will of course not happen with non-undef conditions, so this was not testing anything realistic. Additionally this illustrates potential unsoundness: While GetUnderlyingObject will pick the first operand, the select might be later replaced by the second operand, resulting in inconsistent assumptions about the undef value. Differential Revision: https://reviews.llvm.org/D82261
2020-06-21[ValueTracking] improve analysis for fdiv with same operandsSanjay Patel1-2/+3
(The 'nnan' variant of this pattern is already tested to produce '1.0'.) https://alive2.llvm.org/ce/z/D4hPBy define i1 @src(float %x, i32 %y) { %0: %d = fdiv float %x, %x %uge = fcmp uge float %d, 0.000000 ret i1 %uge } => define i1 @tgt(float %x, i32 %y) { %0: ret i1 1 } Transformation seems to be correct!
2020-05-26[FPEnv] Intrinsic llvm.roundevenSerge Pavlov1-0/+5
This intrinsic implements IEEE-754 operation roundToIntegralTiesToEven, and performs rounding to the nearest integer value, rounding halfway cases to even. The intrinsic represents the missed case of IEEE-754 rounding operations and now llvm provides full support of the rounding operations defined by the standard. Differential Revision: https://reviews.llvm.org/D75670
2020-05-23[ValueTracking] Use assumptions in computeConstantRange.Florian Hahn1-1/+32
This patch updates computeConstantRange to optionally take an assumption cache as argument and use the available assumptions to limit the range of the result. Currently this is limited to assumptions that are comparisons. Reviewers: reames, nikic, spatel, jdoerfert, lebedev.ri Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D76193
2020-05-20Make Value::getPointerAlignment() return an Align, not a MaybeAlign.Eli Friedman1-3/+2
If we don't know anything about the alignment of a pointer, Align(1) is still correct: all pointers are at least 1-byte aligned. Included in this patch is a bugfix for an issue discovered during this cleanup: pointers with "dereferenceable" attributes/metadata were assumed to be aligned according to the type of the pointer. This wasn't intentional, as far as I can tell, so Loads.cpp was fixed to stop making this assumption. Frontends may need to be updated. I updated clang's handling of C++ references, and added a release note for this. Differential Revision: https://reviews.llvm.org/D80072
2020-05-16[ValueTracking] Fix computeKnownBits() with bitwidth-changing ptrtointNikita Popov1-46/+48
computeKnownBitsFromAssume() currently asserts if m_V matches a ptrtoint that changes the bitwidth. Because InstCombine canonicalizes ptrtoint instructions to use explicit zext/trunc, we never ran into the issue in practice. I'm adding unit tests, as I don't know if this can be triggered via IR anywhere. Fix this by calling anyextOrTrunc(BitWidth) on the computed KnownBits. Note that we are going from the KnownBits of the ptrtoint result to the KnownBits of the ptrtoint operand, so we need to truncate if the ptrtoint zexted and anyext if the ptrtoint truncated. Differential Revision: https://reviews.llvm.org/D79234
2020-05-13[ValueTracking] Fix crash in isGuaranteedNotToBeUndefOrPoison when V is in ↵Juneyoung Lee1-1/+6
an unreachable block Summary: This fixes PR45885 by fixing isGuaranteedNotToBeUndefOrPoison so it does not look into dominating branch conditions of V when V is an instruction in an unreachable block. Reviewers: spatel, nikic, lebedev.ri Reviewed By: nikic Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D79790
2020-05-13[ValueTracking] Let propagatesPoison support binops/unaryops/cast/etc.Juneyoung Lee1-25/+12
Summary: This patch makes propagatesPoison be more accurate by returning true on more bin ops/unary ops/casts/etc. The changed test in ScalarEvolution/nsw.ll was introduced by https://github.com/llvm/llvm-project/commit/a19edc4d15b0dae0210b90615775edd76f021008 . IIUC, the goal of the tests is to show that iv.inc's SCEV expression still has no-overflow flags even if the loop isn't in the wanted form. It becomes more accurate with this patch, so think this is okay. Reviewers: spatel, lebedev.ri, jdoerfert, reames, nikic, sanjoy Reviewed By: spatel, nikic Subscribers: regehr, nlopes, efriedma, fhahn, javed.absar, llvm-commits, hiraditya Tags: #llvm Differential Revision: https://reviews.llvm.org/D78615
2020-05-06[SVE] Fix invalid uses of VectorType::getNumElements() in ValueTrackingChristopher Tetreault1-88/+133
Summary: Any function in this module that make use of DemandedElts laregely does not work with scalable vectors. DemandedElts is used to define which elements of the vector to look at. At best, for scalable vectors, we can express the first N elements of the vector. However, in practice, most code that uses these functions expect to be able to talk about the entire vector. In principle, this module should be able to be extended to work with scalable vectors. However, before we can do that, we should ensure that it does not cause code with scalable vectors to miscompile. All functions that use a DemandedElts will bail out if the vector is scalable. Usages of getNumElements() are updated to go through FixedVectorType pointers. Reviewers: rengolin, efriedma, sdesmalen, c-rhodes, spatel Reviewed By: efriedma Subscribers: david-arm, tschuett, kristof.beyls, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D79053
2020-05-05[ValueTracking] fix CannotBeNegativeZero() to disregard 'nsz' FMFSanjay Patel1-5/+3
The 'nsz' flag is different than 'nnan' or 'ninf' in that it does not create poison. Make that explicit in the LangRef and fix ValueTracking analysis that misinterpreted the definition. This manifests as bugs in InstSimplify shown in the test diffs and as discussed in PR45778: https://bugs.llvm.org/show_bug.cgi?id=45778 Differential Revision: https://reviews.llvm.org/D79422
2020-05-02[ValueTracking] Short-circuit GEP known bits calculation (NFC)Nikita Popov1-0/+4
Don't compute known bits of all GEP operands, if we already know that we don't know anything.
2020-04-30[NFC] Rename *ByValOrInalloca* to *PassPointeeByValue*Arthur Eubanks1-1/+1
Summary: In preparation for preallocated. Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D79152
2020-04-25[ValueTracking] Let isGuaranteedNotToBeUndefOrPoison look into more ↵Juneyoung Lee1-17/+47
constants/instructions Summary: This patch helps isGuaranteedNotToBeUndefOrPoison look into more constants and instructions (bitcast/alloca/gep/fcmp). To deal with bitcast, Depth is added to isGuaranteedNotToBeUndefOrPoison. This patch is splitted from https://reviews.llvm.org/D75808. Checked with Alive2 Reviewers: reames, jdoerfert Reviewed By: jdoerfert Subscribers: sanwou01, spatel, llvm-commits, hiraditya Tags: #llvm Differential Revision: https://reviews.llvm.org/D76010
2020-04-24[AssumeBundles] Use assume bundles in isKnownNonZeroTyker1-0/+11
Summary: Use nonnull and dereferenceable from an assume bundle in isKnownNonZero Reviewers: jdoerfert, nikic, lebedev.ri, reames, fhahn, sstefan1 Reviewed By: jdoerfert Subscribers: fhahn, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D76149
2020-04-23[ValueTracking] Handle shufflevector constants in ComputeNumSignBitsEli Friedman1-1/+5
Differential Revision: https://reviews.llvm.org/D78688
2020-04-23Change callbr to only define its output SSA variable on the normalJames Y Knight1-1/+1
path, not the indirect targets. Fixes: PR45565. Differential Revision: https://reviews.llvm.org/D78341
2020-04-23[CallSite removal][ValueTracking] Replace CallSite with CallBase. NFC"Craig Topper1-10/+9
2020-04-23[SVE] Remove calls to VectorType::isScalable from analysisChristopher Tetreault1-1/+1
Reviewers: efriedma, sdesmalen, chandlerc, sunfish Reviewed By: efriedma Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77692
2020-04-23[ValueTracking] Let analyses assume a value cannot be partially poisonJuneyoung Lee1-6/+6
Summary: This is RFC for fixes in poison-related functions of ValueTracking. These functions assume that a value can be poison bitwisely, but the semantics of bitwise poison is not clear at the moment. Allowing a value to have bitwise poison adds complexity to reasoning about correctness of optimizations. This patch makes the analysis functions simply assume that a value is either fully poison or not, which has been used to understand the correctness of a few previous optimizations. The bitwise poison semantics seems to be only used by these functions as well. In terms of implementation, using value-wise poison concept makes existing functions do more precise analysis, which is what this patch contains. Reviewers: spatel, lebedev.ri, jdoerfert, reames, nikic, nlopes, regehr Reviewed By: nikic Subscribers: fhahn, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D78503
2020-04-23Revert "RFC: [ValueTracking] Let analyses assume a value cannot be partially ↵Juneyoung Lee1-6/+6
poison" This reverts commit 80faa8c3af856df93faf909f21cdcc397bed068f.
2020-04-23RFC: [ValueTracking] Let analyses assume a value cannot be partially poisonJuneyoung Lee1-6/+6
Summary: This is RFC for fixes in poison-related functions of ValueTracking. These functions assume that a value can be poison bitwisely, but the semantics of bitwise poison is not clear at the moment. Allowing a value to have bitwise poison adds complexity to reasoning about correctness of optimizations. This patch makes the analysis functions simply assume that a value is either fully poison or not, which has been used to understand the correctness of a few previous optimizations. The bitwise poison semantics seems to be only used by these functions as well. In terms of implementation, using value-wise poison concept makes existing functions do more precise analysis, which is what this patch contains. Reviewers: spatel, lebedev.ri, jdoerfert, reames, nikic, nlopes, regehr Reviewed By: nikic Subscribers: fhahn, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D78503
2020-04-22[CallSite removal][ValueTracking] Use CallBase instead of ImmutableCallSite ↵Craig Topper1-5/+5
for getIntrinsicForCallSite. NFC Differential Revision: https://reviews.llvm.org/D78613
2020-04-21[Analysis] recognize the 'null' pointer constant as not poisonSanjay Patel1-2/+3
Differential Revision: https://reviews.llvm.org/D78575
2020-04-15[ValueTracking] Implement canCreatePoisonJuneyoung Lee1-0/+85
Summary: This PR adds `canCreatePoison(Instruction *I)` which returns true if `I` can generate poison from non-poison operands. Reviewers: spatel, nikic, lebedev.ri Reviewed By: spatel Subscribers: hiraditya, llvm-commits, regehr, nlopes Tags: #llvm Differential Revision: https://reviews.llvm.org/D77890
2020-04-09Clean up usages of asserting vector getters in TypeChristopher Tetreault1-23/+27
Summary: Remove usages of asserting vector getters in Type in preparation for the VectorType refactor. The existence of these functions complicates the refactor while adding little value. Reviewers: sunfish, sdesmalen, efriedma Reviewed By: efriedma Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77273
2020-04-09[KnownBits] Move AND, OR and XOR logic into KnownBitsJay Foad1-15/+4
Summary: There are at least three clients for KnownBits calculations: ValueTracking, SelectionDAG and GlobalISel. To reduce duplication the common logic should be moved out of these clients and into KnownBits itself. This patch does this for AND, OR and XOR calculations by implementing and using appropriate operator overloads KnownBits::operator& etc. Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74060
2020-04-09[ValueTracking] Simplify KnownBits constructionJay Foad1-3/+3
Use the simpler BitWidth constructor instead of the copy constructor to make it clear when we don't actually need to copy an existing KnownBits value. Split out from D74539. NFC.
2020-04-06[ValueTracking] enhance matching of umin/umax with 'not' operandsSanjay Patel1-11/+25
The cmyk test is based on the known regression that resulted from: rGf2fbdf76d8d0 This improves on the equivalent signed min/max change: rG867f0c3c4d8c The underlying icmp equivalence is: ~X pred ~Y --> Y pred X For an icmp with constant, canonicalization results in a swapped pred: ~X < C --> X > ~C
2020-04-05[ValueTracking] enhance matching of smin/smax with 'not' operandsSanjay Patel1-13/+26
The cmyk tests are based on the known regression that resulted from: rGf2fbdf76d8d0 So this improvement in analysis might be enough to restore that commit.
2020-04-05[ValueTracking] Use Inst::comesBefore in isValidAssumeForCtx (NFC).Florian Hahn1-31/+24
D51664 added Instruction::comesBefore which should provide better performance than the manual check. Reviewers: rnk, nikic, spatel Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D76228
2020-03-31Remove "mask" operand from shufflevector.Eli Friedman1-3/+3
Instead, represent the mask as out-of-line data in the instruction. This should be more efficient in the places that currently use getShuffleVector(), and paves the way for further changes to add new shuffles for scalable vectors. This doesn't change the syntax in textual IR. And I don't currently plan to change the bitcode encoding in this patch, although we'll probably need to do something once we extend shufflevector for scalable types. I expect that once this is finished, we can then replace the raw "mask" with something more appropriate for scalable vectors. Not sure exactly what this looks like at the moment, but there are a few different ways we could handle it. Maybe we could try to describe specific shuffles. Or maybe we could define it in terms of a function to convert a fixed-length array into an appropriate scalable vector, using a "step", or something like that. Differential Revision: https://reviews.llvm.org/D72467
2020-03-30[ConstantFold][NFC] Compile time optimization for large vectorsThomas Raoux1-1/+7
Optimize the common case of splat vector constant. For large vector going through all elements is expensive. For splatr/broadcast cases we can skip going through all elements. Differential Revision: https://reviews.llvm.org/D76664
2020-03-24[ValueTracking] improve undef/poison analysis for constant vectorsSanjay Patel1-3/+16
Differential Revision: https://reviews.llvm.org/D76702
2020-03-22[ValueTracking] Avoid blind cast from Operator to InstructionBjorn Pettersson1-8/+11
Summary: Avoid blind cast from Operator to ExtractElementInst in computeKnownBitsFromOperator. This resulted in some crashes in downstream fuzzy testing. Instead we use getOperand directly on the Operator when accessing the vector/index operands. Haven't seen any problems with InsertElement and ShuffleVector, but I believe those could be used in constant expressions as well. So the same kind of fix as for ExtractElement was also applied for InsertElement. When it comes to ShuffleVector we now simply bail out if a dynamic cast of the Operator to ShuffleVectorInst fails. I've got no reproducer indicating problems for ShuffleVector, and a fix would be slightly more complicated as getShuffleDemandedElts is involved. Reviewers: RKSimon, nikic, spatel, efriedma Reviewed By: RKSimon Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D76564
generated by cgit v1.1 at 2025-10-13 17:32:26 +0000