aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/IR/Constants.cpp
AgeCommit message (Collapse)AuthorFilesLines
2023-11-07[IR] Remove FP cast constant expressions (#71408)Nikita Popov1-94/+2
Remove support for the fptrunc, fpext, fptoui, fptosi, uitofp and sitofp constant expressions. All places creating them have been removed beforehand, so this just removes the APIs and uses of these constant expressions in tests. With this, the only remaining FP operation that still has constant expression support is fcmp. This is part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179.
2023-11-06[IR] Mark FP casts constant exprs as undesirableNikita Popov1-2/+2
We will no longer generate these constant expressions by default, but they can still be explicitly created.
2023-11-03[IR] Remove zext and sext constant expressions (#71040)Nikita Popov1-67/+24
Remove support for zext and sext constant expressions. All places creating them have been removed beforehand, so this just removes the APIs and uses of these constant expressions in tests. There is some additional cleanup that can be done on top of this, e.g. we can remove the ZExtInst vs ZExtOperator footgun. This is part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179.
2023-10-05[llvm] Replace uses of Type::getPointerTo (NFC)JOE19941-1/+1
opaque pointer clean-up effort (NFC)
2023-10-02[IR] Mark zext/sext constant expressions as undesirableNikita Popov1-0/+22
Introduce isDesirableCastOp() which determines whether IR builder and constant folding should produce constant expressions for a given cast type. This mirrors what we do for binary operators. Mark zext/sext as undesirable, which prevents most creations of such constant expressions. This is still somewhat incomplete and there are a few more places that can create zext/sext expressions. This is part of the work for https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179. The reason for the odd result in the constantexpr-fneg.c test is that initially the "a[]" global is created with an [0 x i32] type, at which point the icmp expression cannot be folded. Later it is replaced with an [1 x i32] global and the icmp gets folded away. But at that point we no longer fold the zext.
2023-08-22[IR] Remove support for and/or constant expressionsNikita Popov1-10/+2
As part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179, this removes support for and and or constant expressions. Places creating such expressions have been migrated in advance, so this is mostly API removal and test updates. Differential Revision: https://reviews.llvm.org/D155924
2023-08-13[llvm] Drop some more typed pointer bitcasts etc.Bjorn Pettersson1-1/+1
2023-07-31Reapply [IR] Mark and/or constant expressions as undesirableNikita Popov1-2/+2
Reapply after D156401, which stops PatternMatch from recognizing binop constant expressions, which should avoid the infinite loops and assertion failures this patch previously exposed. ----- In preparation for removing support for and/or expressions, mark them as undesirable. As such, we will no longer implicitly create such expressions, but they still exist.
2023-07-26Revert "Reapply [IR] Mark and/or constant expressions as undesirable"Matthew Voss1-2/+2
This reverts commit 0cab8d20417c0e2ccc1ffc5505e080126f5de8e6. Reverted due to an LTO crash. I've put a reduced test case here: https://github.com/llvm/llvm-project/issues/64114
2023-07-25Reapply [IR] Mark and/or constant expressions as undesirableNikita Popov1-2/+2
This reapplies the change for and, but also marks or as undesirable at the same time. Only handling one of them can cause infinite combine loops due to the asymmetric handling. ----- In preparation for removing support for and/or expressions, mark them as undesirable. As such, we will no longer implicitly create such expressions, but they still exist.
2023-07-21Revert "Reapply [IR] Mark and constant expressions as undesirable"Nathan Chancellor1-1/+1
This reverts commit 086ee99564afbb11449c08ea2e094f7f49fadde5. This patch causes an infinite loop when building arch/mips/mm/c-r4k.c in the Linux kernel. See the comment in Phabricator for a reduced reproducer: https://reviews.llvm.org/rG086ee99564afbb11449c08ea2e094f7f49fadde5
2023-07-21Reapply [IR] Mark and constant expressions as undesirableNikita Popov1-1/+1
Reapply after fixing an issue in canonicalizeLogicFirst() exposed by this change (218f97578b26f7a89f7f8ed0748c31ef0181f80a). ----- In preparation for removing support for and expressions, mark them as undesirable. As such, we will no longer implicitly create such expressions, but they still exist.
2023-07-20Revert "[IR] Mark add constant expressions as undesirable"Nikita Popov1-1/+1
This reverts commit f8a36d8c3e264c4fccf8058e699201a452ea7bb7. I believe this is causing an assertion failure on the sanitizer-x86_64-linux buildbot: clang++: /b/sanitizer-x86_64-linux/build/llvm-project/llvm/include/llvm/Support/Casting.h:578: decltype(auto) llvm::cast(From *) [To = llvm::BinaryOperator, From = llvm::Value]: Assertion `isa<To>(Val) && "cast<Ty>() argument of incompatible type!"' failed. #10 0x000055bdd7e82408 canonicalizeLogicFirst(llvm::BinaryOperator&, llvm::IRBuilder<llvm::TargetFolder, llvm::IRBuilderCallbackInserter>&) /b/sanitizer-x86_64-linux/build/llvm-project/llvm/lib/Transforms/InstCombine/InstCombineAndOrXor.cpp:2131:5 #11 0x000055bdd7e80183 llvm::InstCombinerImpl::visitAnd(llvm::BinaryOperator&) /b/sanitizer-x86_64-linux/build/llvm-project/llvm/lib/Transforms/InstCombine/InstCombineAndOrXor.cpp:2661:20 Likely the code is encountering a constant expression in a case it didn't before.
2023-07-20[IR] Mark add constant expressions as undesirableNikita Popov1-1/+1
In preparation for removing support for add expressions, mark them as undesirable. As such, we will no longer implicitly create such expressions, but they still exist.
2023-07-18[Constants] Use getGEPReturnType() (NFC)Nikita Popov1-18/+7
This reimplements essentially the same logic.
2023-07-18[llvm] Remove some uses of isOpaqueOrPointeeTypeEquals() (NFC)Nikita Popov1-1/+0
2023-07-14[llvm] Remove uses of hasSameElemenTypeAs() (NFC)Nikita Popov1-15/+0
Always returns true with opaque pointers.
2023-04-20[IR] Remove dead code for unsupported ConstantExpr binopsJay Foad1-13/+0
2023-04-04[IR] Remove ConstantFP::getZeroValueForNegation.Craig Topper1-7/+0
This was mostly used for integers which was fixed in D147492. The only FP usage was removed in D147497. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D147501
2023-04-04[IR] Remove uses of the oddly named ConstantFP::getZeroValueForNegation in ↵Craig Topper1-2/+1
integer code. Confusingly ConstantFP's getZeroValueForNegation intentionally handles non-FP constants. It calls getNullValue in Constant. Nearly all uses in tree are for integers rather than FP. Maybe due to replacing FSub -0.0, X idiom with an FNeg instructions a few years ago. This patch replaces all the integer uses in tree with ConstantInt::get(0, Ty). The one remaining use is in clang with a FIXME that it should use fneg. I'll fix that next and then delete ConstantFP::getZeroValueForNegation. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D147492
2023-03-22[Constant] Inline ConstantInt::getSignedCraig Topper1-8/+0
ConstantInt::getSigned calls ConstantInt::get with the IsSigned flag set to true. That flag normally defaults to false. For always signed constants the code base is not consistent about whether it uses ConstantInt::getSigned or ConstantInt::get with IsSigned set to true. And it's not clear how to decide which way to use. By making getSigned inline, both ways should generate the same code in the end. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D146598
2023-03-16[IR] Remove unused ConstantExpr::getOffsetOf() methods (NFC)Nikita Popov1-18/+0
These are not used and should not be used (just like anything that creates a constant expression only due to lack of DL-awareness).
2023-03-16[ConstExpr] Remove select constant expressionNikita Popov1-23/+0
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
2023-03-14[LLVM] Remove support for constant scalable vector GEPs.Paul Walker1-0/+1
This work has fallen out from D134648 as a requirement to loosen the "constness" of vscale. Differential Revision: https://reviews.llvm.org/D145404
2023-03-06[IR] Remove ConstantExpr::getUMin() (NFC)Nikita Popov1-5/+0
This is part of select constant expression removal. As there is only a single place where this is used, just expand it to explicit constant folding calls. (Normally we'd just use the IRBuilder here, but this isn't possible due to mergeUndefsWith use).
2023-02-27[LLVMContextImpl] Separate out integer constant onesArthur Eubanks1-2/+3
Very small compile time improvement: https://llvm-compile-time-tracker.com/compare.php?from=6a7a8907e8334eaf551742148079c628f78e6ed7&to=454d1181fbdb9121f0c7a3ecf526520db32ab420&stat=instructions:u Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D144746
2023-02-27[LLVMContextImpl] Separate out integer constant zeroesArthur Eubanks1-1/+3
Very small compile time improvement: https://llvm-compile-time-tracker.com/compare.php?from=a628ca4925f7249b4fbd3e932c9627b12e2770dd&to=6a7a8907e8334eaf551742148079c628f78e6ed7&stat=instructions:u Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D144745
2023-01-11[IRBuilder] Use canonical i64 type for insertelement index used by vector ↵Paul Walker1-2/+2
splats. Instcombine prefers this canonical form (see getPreferredVectorIndex), as does IRBuilder when passing the index as an integer so we may as well use the prefered form from creation. NOTE: All test changes are mechanical with nothing else expected beyond a change of index type from i32 to i64. Differential Revision: https://reviews.llvm.org/D140983
2023-01-05Move from llvm::makeArrayRef to ArrayRef deduction guides - llvm/ partserge-sans-paille1-1/+1
Use deduction guides instead of helper functions. The only non-automatic changes have been: 1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*)) 2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase. 3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated. 4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that). Per reviewers' comment, some useless makeArrayRef have been removed in the process. This is a follow-up to https://reviews.llvm.org/D140896 that introduced the deduction guides. Differential Revision: https://reviews.llvm.org/D140955
2022-12-26[InstCombine] do not add "nuw" to 1<<X if the "1" has undefined elementsSanjay Patel1-0/+6
This was noted as a potential miscompile in the post-commit feedback for the patch that added this fold: d4493dd1ed58ac3f1eab0
2022-12-20[IR] Add a target extension type to LLVM.Joshua Cranmer1-1/+22
Target-extension types represent types that need to be preserved through optimization, but otherwise are not introspectable by target-independent optimizations. This patch doesn't add any uses of these types by an existing backend, it only provides basic infrastructure such that these types would work correctly. Reviewed By: nikic, barannikov88 Differential Revision: https://reviews.llvm.org/D135202
2022-12-05[IR] llvm::Optional => std::optionalFangrui Song1-1/+1
Many llvm/IR/* files have been migrated by other contributors. This migrates most remaining files.
2022-12-02[IR] Use std::nullopt instead of None (NFC)Kazu Hirata1-1/+1
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-09-26[IR][InstCombine] Support scalable vector splats ConstantExprs in ↵Craig Topper1-0/+5
Constant::getUniqueInteger(). I've left the getAggregateElement as a fast path for non-ConstantExprs to avoid a call to getSplatValue in release builds. Fixes PR57989. Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D134670
2022-09-08[ConstantExpr] Remove fneg expressionNikita Popov1-44/+2
As part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179, this removes the fneg constant expression (which is, incidentally, the only unary operator expression). Differential Revision: https://reviews.llvm.org/D133418
2022-08-28[llvm] Qualify auto in range-based for loops (NFC)Kazu Hirata1-1/+1
2022-07-12[IR] Remove support for float binop constant expressionsNikita Popov1-25/+5
As part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179, this removes support for the floating-point binop constant expressions fadd, fsub, fmul, fdiv and frem. As part of this change, the C APIs LLVMConstFAdd, LLVMConstFSub, LLVMConstFMul, LLVMConstFDiv and LLVMConstFRem are removed. The LLVMBuild APIs should be used instead. Differential Revision: https://reviews.llvm.org/D129478
2022-07-08[ConstantExpr] Don't create float binop expressionsNikita Popov1-5/+5
Mark the fadd, fsub, fmul, fdiv, and frem expressions as undesirable, so they are not created automatically. This is in preparation for their removal.
2022-07-06[IR] Remove Constant::canTrap() (NFC)Nikita Popov1-4/+0
As integer div/rem constant expressions are no longer supported, constants can no longer trap and are always safe to speculate. Remove the Constant::canTrap() method and its usages.
2022-07-06[ConstExpr] Remove div/rem constant expressionsNikita Popov1-60/+30
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-07-05[ConstExpr] Don't create div/rem expressionsNikita Popov1-0/+27
This removes creation of udiv/sdiv/urem/srem constant expressions, in preparation for their removal. I've added a ConstantExpr::isDesirableBinOp() predicate to determine whether an expression should be created for a certain operator. With this patch, div/rem expressions can still be created through explicit IR/bitcode, forbidding them entirely will be the next step. Differential Revision: https://reviews.llvm.org/D128820
2022-07-04[IR] Remove support for insertvalue constant expressionNikita Popov1-42/+2
This removes the insertvalue constant expression, as part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179. This is very similar to the extractvalue removal from D125795. insertvalue is also not supported in bitcode, so no auto-ugprade is necessary. ConstantExpr::getInsertValue() can be replaced with IRBuilder::CreateInsertValue() or ConstantFoldInsertValueInstruction(), depending on whether a constant result is required (with the latter being fallible). The ConstantExpr::hasIndices() and ConstantExpr::getIndices() methods also go away here, because there are no longer any constant expressions with indices. Differential Revision: https://reviews.llvm.org/D128719
2022-06-28[IR] Remove support for extractvalue constant expressionNikita Popov1-36/+1
This removes the extractvalue constant expression, as part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179. extractvalue is already not supported in bitcode, so we do not need to worry about bitcode auto-upgrade. Uses of ConstantExpr::getExtractValue() should be replaced with IRBuilder::CreateExtractValue() (if the fact that the result is constant is not important) or ConstantFoldExtractValueInstruction() (if it is). Though for this particular case, it is also possible and usually preferable to use getAggregateElement() instead. The C API function LLVMConstExtractValue() is removed, as the underlying constant expression no longer exists. Instead, LLVMBuildExtractValue() should be used (which will constant fold or create an instruction). Depending on the use-case, LLVMGetAggregateElement() may also be used instead. Differential Revision: https://reviews.llvm.org/D125795
2022-06-23[IR] Export ConstantFold.h header (NFC)Nikita Popov1-1/+1
This is in preparation for https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179. As part of that change, we'll want to invoke some of these constant folding APIs explicitly, as it won't happen as part of ConstantExpr::getXYZ() anymore. Ideally, we'd merge these with the DL-aware constant folding APIs and only call those, but this is not easily possible for some current usages (most important IRBuilder, which uses DL-independent constant folding by default, and some major layering changes would be needed to change that). This is basically a reboot of D115035 with different motivation. Differential Revision: https://reviews.llvm.org/D128213
2022-06-17[IR] Check for SignedMin/-1 division in canTrap() (PR56038)Nikita Popov1-5/+10
In addition to division by zero, signed division also traps for SignedMin / -1. This was handled in isSafeToSpeculativelyExecute(), but not in Constant::canTrap().
2022-06-13[InstSimplify][IR] Handle trapping constant aggregate (PR49839)Nikita Popov1-12/+16
Unfortunately, it's not just constant expressions that can trap, we might also have a trapping constant expression nested inside a constant aggregate. Perform the check during phi folding on Constant rather than ConstantExpr, and extend the Constant::mayTrap() implementation to also recursive into ConstantAggregates, not just ConstantExprs. Fixes https://github.com/llvm/llvm-project/issues/49839.
2022-06-10[InstCombine] Use +0.0 instead of -0.0 as the FP identity for some foldsDavid Sherwood1-6/+4
In foldSelectIntoOp we sometimes transform a select of a fadd into a fadd of a select, where we select between data and an identity value. For both fadd and fsub the identity is always -0.0, but if the nsz flag is set on the select instruction we can use +0.0 instead. Doing so then triggers other optimisations, such as when folding the select of masked load into a new masked load. Differential Revision: https://reviews.llvm.org/D126774
2022-05-25[LLVM][IR] Fix assert in ConstantExpr::getPtrToInt so all vector types are ↵Paul Walker1-2/+2
supported. Fixes: #55410
2022-05-05[IR] Simplify code. NFCI.Benjamin Kramer1-14/+2
2022-05-02[InstCombine] Handle non-canonical GEP index in indexed compare fold (PR55228)Nikita Popov1-0/+11
Normally the index type will already be canonicalized here, but this is not guaranteed depending on visitation order. The code was already accounting for a potentially needed sext, but a trunc may also be needed. Add a ConstantExpr::getSExtOrTrunc() helper method to make this simpler. This matches the corresponding IRBuilder method in behavior. Fixes https://github.com/llvm/llvm-project/issues/55228.
generated by cgit v1.1 at 2025-10-15 22:19:20 +0000