aboutsummaryrefslogtreecommitdiff
path: root/llvm/unittests/Analysis/ValueTrackingTest.cpp
AgeCommit message (Collapse)AuthorFilesLines
2023-04-13ValueTracking: Handle no-nan check for computeKnownFPClass for fmulMatt Arsenault1-0/+17
Copy the logic from isKnownNeverNaN for fadd/fsub. Leave the extension to handle the zero case for a future change.
2023-04-12unittests: Use opaque pointers in a testMatt Arsenault1-90/+90
2023-04-12ValueTracking: Handle no-nan check for computeKnownFPClass for fadd/fsubMatt Arsenault1-1/+36
Copy the logic from isKnownNeverNaN for fadd/fsub.
2023-03-16ValueTracking: Handle nofpclass in computeKnownFPClassMatt Arsenault1-0/+77
2023-03-16ValueTracking: Add start of computeKnownFPClass APIMatt Arsenault1-0/+205
Add a new compute-known-bits like function to compute all the interesting floating point properties at once. Eventually this should absorb all the various floating point queries we already have.
2023-03-16[ConstExpr] Remove select constant expressionNikita Popov1-4/+1
This removes the select constant expression, as part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179. Uses of this expressions have already been removed in advance, so this just removes related infrastructure and updates tests. Differential Revision: https://reviews.llvm.org/D145382
2022-12-19[ValueTracking] Consider single poison operands in propgatesPoison.Florian Hahn1-60/+83
This patch updates propgatesPoison to take a Use as argument and propagatesPoison now returns true if the passed in operand causes the user to yield poison if the operand is poison This allows propagating poison if the condition of a select is poison. This helps improve results for programUndefinedIfUndefOrPoison. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D111643
2022-12-15[NFC] Rename Instruction::insertAt() to Instruction::insertInto(), to be ↵Vasileios Porpodas1-1/+1
consistent with BasicBlock::insertInto() Differential Revision: https://reviews.llvm.org/D140085
2022-12-12[NFC] Cleanup: Replaces BB->getInstList().insert() with I->insertAt().Vasileios Porpodas1-1/+1
This is part of a series of cleanup patches towards making BasicBlock::getInstList() private. Differential Revision: https://reviews.llvm.org/D138877
2022-12-02[llvm/unittests] Use std::nullopt instead of None (NFC)Kazu Hirata1-4/+4
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-08-25[ValueTracking][InstCombine] restrict FP min/max matching to avoid miscompileSanjay Patel1-16/+16
This is a long-standing FIXME with a non-FMF test that exposes the bug as shown in issue #57357. It's possible that there's still a way to miscompile by mis-identifying/mis-folding FP min/max patterns, but this patch only exposes a couple of seemingly minor regressions while preventing the broken transform.
2022-07-24[ValueTracking] allow vector types in isImpliedCondition()Sanjay Patel1-1/+1
The matching of constants assumed integers, but we can handle splat vector constants seamlessly with m_APInt.
2022-07-24[ValueTracking] add test for isImpliedCondition with vector types; NFCSanjay Patel1-0/+12
2022-07-06[ConstExpr] Remove div/rem constant expressionsNikita Popov1-14/+0
D128820 stopped creating div/rem constant expressions by default; this patch removes support for them entirely. The getUDiv(), getExactUDiv(), getSDiv(), getExactSDiv(), getURem() and getSRem() on ConstantExpr are removed, and ConstantExpr::get() now only accepts binary operators for which ConstantExpr::isSupportedBinOp() returns true. Uses of these methods may be replaced either by corresponding IRBuilder methods, or ConstantFoldBinaryOpOperands (if a constant result is required). On the C API side, LLVMConstUDiv, LLVMConstExactUDiv, LLVMConstSDiv, LLVMConstExactSDiv, LLVMConstURem and LLVMConstSRem are removed and corresponding LLVMBuild methods should be used. Importantly, this also means that constant expressions can no longer trap! This patch still keeps the canTrap() method to minimize diff -- I plan to drop it in a separate NFC patch. Differential Revision: https://reviews.llvm.org/D129148
2022-02-16[ValueTracking] Checking haveNoCommonBitsSet for (x & y) and ~(x | y)Chuanqi Xu1-0/+56
This one tries to fix: https://github.com/llvm/llvm-project/issues/53357. Simply, this one would check (x & y) and ~(x | y) in haveNoCommonBitsSet. Since they shouldn't have common bits (we could traverse the case by enumerating), and we could convert this one to (x & y) | ~(x | y) . Then the compiler could handle it in InstCombineAndOrXor. Further more, since ((x & y) + (~x & ~y)) would be converted to ((x & y) + ~(x | y)), this patch would fix it too. https://alive2.llvm.org/ce/z/qsKzRS Reviewed By: spatel, xbolva00, RKSimon, lebedev.ri Differential Revision: https://reviews.llvm.org/D118094
2022-02-14[NFC] Precommit for PR53357Chuanqi Xu1-1/+1
Due to there are other required changes in https://reviews.llvm.org/D118094, precommit these changes to ease reviewing. Including: - Remove *_thwart tests. - Remove test for (x & y) + (~x & ~y) - Fix incorrect uniitest committeed before
2022-02-14[NFC] [ValueTracking] Add unittest for haveNoCommonBitsSetChuanqi Xu1-0/+22
2021-12-28[Analysis] allow caller to choose signed/unsigned when computing constant rangeSanjay Patel1-10/+10
We should not lose analysis precision if an 'add' has both no-wrap flags (nsw and nuw) compared to just one or the other. This patch is modeled on a similar construct that was added with D59386. I don't think it is possible to expose a problem with an unsigned compare because of the way this was coded (nuw is handled first). InstCombine has an assert that fires with the example from: https://github.com/llvm/llvm-project/issues/52884 ...because it was expecting InstSimplify to handle this kind of pattern with an smax. Fixes #52884 Differential Revision: https://reviews.llvm.org/D116322
2021-12-20[Analysis] fix cast in ValueTracking to allow constant expressionSanjay Patel1-0/+14
The test would crash because a non-instruction negate op made it in here. Fixes #51506
2021-09-24[Analysis] Fix another issue when querying vscale attributes on functionsDavid Sherwood1-1/+11
There are several places in the code that are currently broken where we assume an Instruction is always a member of a BasicBlock that lives in a Function. This is a problem specifically when attempting to get the vscale_range attribute. This patch adds checks that an Instruction's parent also has a parent! I've added a test for a function-less @llvm.vscale intrinsic call here: unittests/Analysis/ValueTrackingTest.cpp
2021-09-24[Analysis] Fix issues when querying vscale attributes on functionsDavid Sherwood1-0/+17
There are several places in the code that are currently broken as they assume an Instruction always has a parent Function when attempting to get the vscale_range attribute. This patch adds checks that an Instruction has a parent. I've added a test for a parentless @llvm.vscale intrinsic call here: unittests/Analysis/ValueTrackingTest.cpp Differential Revision: https://reviews.llvm.org/D110158
2021-09-21[ValueTracking,VectorCombine] Allow passing DT to computeConstantRange.Florian Hahn1-1/+1
isValidAssumeForContext can provide better results with access to the dominator tree in some cases. This patch adjusts computeConstantRange to allow passing through a dominator tree. The use VectorCombine is updated to pass through the DT to enable additional scalarization. Note that similar APIs like computeKnownBits already accept optional dominator tree arguments. Reviewed By: lebedev.ri Differential Revision: https://reviews.llvm.org/D110175
2021-09-13[value-tracking] see through returned attribute.Florian Mayer1-0/+16
Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D109675
2021-08-02[ValueTracking] Fix computeConstantRange to use "may" instead of "always" ↵Chang-Sun Lin, Jr1-6/+34
semantics for llvm.assume ValueTracking should allow for value ranges that may satisfy llvm.assume, instead of restricting the ranges only to values that will always satisfy the condition. Differential Revision: https://reviews.llvm.org/D107298
2021-06-17Update @llvm.powi to handle different int sizes for the exponentBjorn Pettersson1-2/+2
This can be seen as a follow up to commit 0ee439b705e82a4fe20e2, that changed the second argument of __powidf2, __powisf2 and __powitf2 in compiler-rt from si_int to int. That was to align with how those runtimes are defined in libgcc. One thing that seem to have been missing in that patch was to make sure that the rest of LLVM also handle that the argument now depends on the size of int (not using the si_int machine mode for 32-bit). When using __builtin_powi for a target with 16-bit int clang crashed. And when emitting libcalls to those rtlib functions, typically when lowering @llvm.powi), the backend would always prepare the exponent argument as an i32 which caused miscompiles when the rtlib was compiled with 16-bit int. The solution used here is to use an overloaded type for the second argument in @llvm.powi. This way clang can use the "correct" type when lowering __builtin_powi, and then later when emitting the libcall it is assumed that the type used in @llvm.powi matches the rtlib function. One thing that needed some extra attention was that when vectorizing calls several passes did not support that several arguments could be overloaded in the intrinsics. This patch allows overload of a scalar operand by adding hasVectorInstrinsicOverloadedScalarOpd, with an entry for powi. Differential Revision: https://reviews.llvm.org/D99439
2021-06-16[ValueTracking] add FP intrinsics to test for propagatesPoison; NFCSanjay Patel1-1/+59
I'm not sure what behavior we want if the FP environment is not default (also not sure if there's a way to enumerate the full list of intrinsics programmatically), but currently these are all defaulting to 'false' (doesn't propagate).
2021-06-16[ValueTracking] add tests for propagatesPoison with FP ops; NFCSanjay Patel1-0/+6
Verify that this matches the behavior in InstSimplify: D104383 / ce95200b7942 We still need to add code/tests for FP intrinsics.
2021-06-08ValueTrackingTest.cpp - Pass DataLayout by reference. NFCI.Simon Pilgrim1-8/+8
2021-05-14Bump googletest to 1.10.0Benjamin Kramer1-4/+4
2021-04-14[ValueTracking] match negative-stepping non-zero recurrenceSanjay Patel1-1/+1
This is pulled out of D100408. This avoids a regression that would be exposed by making the calling code from InstSimplify more efficient.
2021-04-14[ValueTracking] add unit test for isKnownNonZero(); NFCSanjay Patel1-0/+21
We call various value tracking APIs from within -instsimplify, so I don't think this is visible in a larger test.
2021-04-01[ValueTracking] Add with.overflow intrinsics to poison analysis functionsJuneyoung Lee1-5/+36
This is a patch teaching ValueTracking that `s/u*.with.overflow` intrinsics do not create undef/poison and they propagate poison. I couldn't write a nice example like the one with ctpop; ValueTrackingTest.cpp were simply updated to check these instead. This patch helps reducing regression while fixing https://llvm.org/pr49688 . Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D99671
2021-01-24[ValueTracking] Don't assume readonly function will returnNikita Popov1-7/+14
This is similar to D94106, but for the isGuaranteedToTransferExecutionToSuccessor() helper. We should not assume that readonly functions will return, as this is only true for mustprogress functions (in which case we already infer willreturn). As with the DCE change, for now continue assuming that readonly intrinsics will return, as not all target intrinsics have been annotated yet. Differential Revision: https://reviews.llvm.org/D95288
2021-01-19[ValueTracking] Strengthen impliesPoison reasoningNikita Popov1-0/+40
Split impliesPoison into two recursive walks, one over V, the other over ValAssumedPoison. This allows us to reason about poison implications in a number of additional cases that are important in practice. This is a generalized form of D94859, which handles the cmp to cmp implication in particular. Differential Revision: https://reviews.llvm.org/D94866
2021-01-13[ValueTracking] Fix one s/dyn_cast/dyn_cast_or_null/Markus Lavin1-1/+6
Handle if Constant::getAggregateElement() returns nullptr in canCreateUndefOrPoison(). Differential Revision: https://reviews.llvm.org/D94494
2021-01-06[Constant] Add containsPoisonElementJuneyoung Lee1-0/+24
This patch - Adds containsPoisonElement that checks existence of poison in constant vector elements, - Renames containsUndefElement to containsUndefOrPoisonElement to clarify its behavior & updates its uses properly With this patch, isGuaranteedNotToBeUndefOrPoison's tests w.r.t constant vectors are added because its analysis is improved. Thanks! Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D94053
2021-01-05[ValueTracking] isGuaranteedNotToBePoison should return true on undefJuneyoung Lee1-0/+4
This is a one-line fix to isGuaranteedNotToBePoison to return true if undef is given.
2020-12-29[ValueTracking] Implement impliesPoisonJuneyoung Lee1-0/+53
This PR adds impliesPoison(ValAssumedPoison, V) that returns true if V is poison under the assumption that ValAssumedPoison is poison. For example, impliesPoison('icmp X, 10', 'icmp X, Y') return true because 'icmp X, Y' is poison if 'icmp X, 10' is poison. impliesPoison can be used for sound optimization of select, as discussed in D77868. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D78152
2020-12-28[ValueTracking] Use m_LogicalAnd/Or to look into conditionsJuneyoung Lee1-0/+62
This patch updates isImpliedCondition/isKnownNonZero to look into select form of and/or as well. See llvm.org/pr48353 and D93065 for more context Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D93845
2020-12-28[ValueTracking] Add unit tests for isKnownNonZero, isImpliedCondition (NFC)Juneyoung Lee1-0/+67
2020-11-27[ValueTracking] Fix assert on shufflevector of pointersNikita Popov1-0/+9
In this case getScalarSizeInBits() is not well-defined. Use the existing TyBits variable that handles vectors of pointers correctly.
2020-10-27[ValueTracking] Add more tests for alignment assume bundlesAlex Richardson1-0/+29
I noticed that alignment was no longer inferred as well after I last merged our CHERI fork from upstream. I opened this review before seeing that D88669 already fixes the same problem, so this commit simply adds the new test that I added as part of this change. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D89830
2020-10-21[ValueTracking] Interpret GEPs as a series of adds multiplied by the related ↵Quentin Colombet1-0/+60
scaling factor Prior to this patch, computeKnownBits would only try to deduce trailing zeros bits for getelementptrs. This patch adds the logic to treat geps as a series of add * scaling factor. Thanks to this patch, using a gep or performing an address computation directly "by hand" (ptrtoint followed by adds and mul followed by inttoptr) offers the same computeKnownBits information. Previously, the "by hand" approach would have given more information. This is related to https://llvm.org/PR47241. Differential Revision: https://reviews.llvm.org/D86364
2020-10-14[ValueTracking] Use assume's noundef operand bundleJuneyoung Lee1-5/+48
This patch updates `isGuaranteedNotToBeUndefOrPoison` to use `llvm.assume`'s `noundef` operand bundle. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D89219
2020-10-08[unittests] Add a few tests for computeKnownBits with rangesQuentin Colombet1-0/+54
These tests make sure that the range information is properly understood during computeKnownBits analysis. NFC Differential Revision: https://reviews.llvm.org/D88934
2020-09-28[ValueTracking] Fix analyses to update CxtI to be phi's incoming edges' ↵Juneyoung Lee1-0/+24
terminators It was mentioned that D88276 that when a phi node is visited, terminators at their incoming edges should be used for CtxI. This is a patch that makes two functions (ComputeNumSignBitsImpl, isGuaranteedNotToBeUndefOrPoison) to do so. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D88360
2020-09-25[ValueTracking] Check uses of Argument if it is given to ↵Juneyoung Lee1-0/+10
isGuaranteedNotToBeUndefOrPoison This is a patch that allows isGuaranteedNotToBeUndefOrPoison to return more precise result when an argument is given, by looking through its uses at the entry block (and following blocks as well, if it is checking poison only). This is useful when there is a function call with noundef arguments at the entry block. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D88207
2020-09-10[ValueTracking] isKnownNonZero, computeKnownBits for freezeJuneyoung Lee1-0/+18
This implements support for isKnownNonZero, computeKnownBits when freeze is involved. ``` br (x != 0), BB1, BB2 BB1: y = freeze x ``` In the above program, we can say that y is non-zero. The reason is as follows: (1) If x was poison, `br (x != 0)` raised UB (2) If x was fully undef, the branch again raised UB (3) If x was non-zero partially undef, say `undef | 1`, `freeze x` will return a nondeterministic value which is also non-zero. (4) If x was just a concrete value, it is trivial Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D75808
2020-09-09[ValueTracking] Add UndefOrPoison/Poison-only version of relevant functionsJuneyoung Lee1-1/+47
This patch adds isGuaranteedNotToBePoison and programUndefinedIfUndefOrPoison. isGuaranteedNotToBePoison will be used at D75808. The latter function is used at isGuaranteedNotToBePoison. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D84242
2020-08-27[ValueTracking] Replace recursion with WorklistVitaly Buka1-1/+1
Now findAllocaForValue can handle nontrivial phi cycles.
generated by cgit v1.1 at 2025-10-19 16:55:23 +0000