aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Analysis/ConstantFolding.cpp
AgeCommit message (Collapse)AuthorFilesLines
2023-11-16[AMDGPU] - Add constant folding for s_bitreplicate (#72366)Jessica Del1-0/+13
If the input is a constant, we can constant fold the s_bitreplicate operation.
2023-11-10[ConstantFolding] Avoid use of ConstantExpr::getLShr() (NFC)Nikita Popov1-3/+2
Work on APInt instead.
2023-11-10[ConstantFolding] Remove unnecessary pointer handling in FoldBitCast (NFCI)Nikita Popov1-9/+0
The destination element type here cannot be a pointer type, as this would require an inttoptr rather than bitcast.
2023-11-01[ConstantFolding] Add ConstantFoldIntegerCast helperNikita Popov1-14/+28
This is intended as the replacement for ConstantExpr::getIntegerCast(), which does not require availability of the corresponding constant expressions. It just forwards to ConstantFoldCastOperand with the correct opcode.
2023-10-02[IR] Mark zext/sext constant expressions as undesirableNikita Popov1-4/+7
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-09-29[ConstantFolding] Avoid some uses of ConstantExpr::getCast()Nikita Popov1-9/+9
Call the constant folding API instead.
2023-09-29[llvm] Use more explicit cast methods (NFC)Nikita Popov1-1/+1
Instead of ConstantExpr::getCast() with a fixed opcode, use the corresponding getXYZ methods instead. For the one place creating a pointer bitcast drop it entirely, as this is redundant with opaque pointers.
2023-09-28[ConstantFolding] Avoid use of ConstantExpr::getZExt() (NFC)Nikita Popov1-3/+8
Use the constant folding API instead, which should always succeed in this case.
2023-09-13Reapply "AMDGPU: Drop and auto-upgrade llvm.amdgcn.ldexp to llvm.ldexp"Matt Arsenault1-11/+0
This reverts commit d9333e360a7c52587ab6e4328e7493b357fb2cf3.
2023-09-13InstSimplify: Simplifications for ldexpMatt Arsenault1-0/+6
Ported from old amdgcn intrinsic which will soon be deleted. https://reviews.llvm.org/D149587
2023-09-02ConstantFolding: Handle exp10 intrinsicMatt Arsenault1-0/+4
https://reviews.llvm.org/D157892
2023-08-22[IR] Remove support for and/or constant expressionsNikita Popov1-13/+0
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-07-28ConstantFolding: remove function in context of opaque ptrsRamkumar Ramachandra1-16/+0
The function StripPtrCastKeepAS() no longer makes any sense, as we've migrated to using opaque pointers throughout the codebase. Hence, remove it. No changes to tests are required. Differential Revision: https://reviews.llvm.org/D156555
2023-07-26[AMDGPU] Propagate constants for llvm.amdgcn.wave.reduce.umin/umaxPravin Jagtap1-0/+5
Reviewed By: arsenm, #amdgpu Differential Revision: https://reviews.llvm.org/D156077
2023-07-24ConstantFolding: Constant fold denormal inputs to canonicalize for IEEEMatt Arsenault1-2/+1
This makes it possible to use canonicalize to perform a dynamic check for whether denormal flushing is enabled, which will fold out when the denormal mode is known. Previously it would only fold if denormal flushing were known enabled. https://reviews.llvm.org/D156107
2023-07-24[ConstantFolding] Avoid use of ConstantExpr::getOr() (NFC)Nikita Popov1-1/+2
Constant folding cannot fail here, because we're really working on plain integers. It might be better to make all of this work on APInts instead of Constants.
2023-07-22ConstantFolding: Fix canonicalize folding for dynamic mode denormal inputsMatt Arsenault1-1/+1
We have to assume the input could be positive-zero. Makes alive2 happy.
2023-07-18[llvm] Remove uses of getWithSamePointeeType() (NFC)Nikita Popov1-6/+4
2023-07-18[ConstantFolding] Remove some typed pointer handling (NFC)Nikita Popov1-12/+2
No need to insert a bitcast.
2023-07-17InstSimplify: Handle basic folds for frexpMatt Arsenault1-7/+73
Handle constant folding and idempotent folding. Not sure this is an appropriate use of undef for the inf/nan case. The C version says the second result is "unspecified". The AMDGPU instruction returns 0.
2023-07-14[llvm] Remove uses of getNonOpaquePointerElementType() (NFC)Nikita Popov1-5/+1
2023-05-17[ConstantFolding] fold integer bitwidth is greater than 63, and not multiple ↵khei41-6/+4
of 8 variables Differential Revision: https://reviews.llvm.org/D150422
2023-05-15[ConstantFold] use StoreSize for VectorType foldingkhei41-2/+8
Differential Revision: https://reviews.llvm.org/D150515 Reviewed By: nikic
2023-04-29LangRef: Add "dynamic" option to "denormal-fp-math"Matt Arsenault1-1/+27
This is stricter than the default "ieee", and should probably be the default. This patch leaves the default alone. I can change this in a future patch. There are non-reversible transforms I would like to perform which are legal under IEEE denormal handling, but illegal with flushing zero behavior. Namely, conversions between llvm.is.fpclass and fcmp with zeroes. Under "ieee" handling, it is legal to translate between llvm.is.fpclass(x, fcZero) and fcmp x, 0. Under "preserve-sign" handling, it is legal to translate between llvm.is.fpclass(x, fcSubnormal|fcZero) and fcmp x, 0. I would like to compile and distribute some math library functions in a mode where it's callable from code with and without denormals enabled, which requires not changing the compares with denormals or zeroes. If an IEEE function transforms an llvm.is.fpclass call into an fcmp 0, it is no longer possible to call the function from code with denormals enabled, or write an optimization to move the function into a denormal flushing mode. For the original function, if x was a denormal, the class would evaluate to false. If the function compiled with denormal handling was converted to or called from a preserve-sign function, the fcmp now evaluates to true. This could also be of use for strictfp handling, where code may be changing the denormal mode. Alternative name could be "unknown". Replaces the old AMDGPU custom inlining logic with more conservative logic which tries to permit inlining for callees with dynamic handling and avoids inlining other mismatched modes.
2023-04-03[IR] Replace calls to ConstantFP::getNullValue with ConstantFP::getZero. NFCCraig Topper1-1/+1
There is no getNullValue in ConstantFP. Due to inheritance, we're calling Constant::getNullValue which handles any type including FP. Since we already know we want an FP constant we can use ConstantFP::getZero which might be faster and is a more readable name for an FP zero.
2023-03-15ConstantFolding: Minor cleanups for is_fpclassMatt Arsenault1-3/+3
2023-03-14[LLVM] Remove support for constant scalable vector GEPs.Paul Walker1-2/+6
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-09[ConstantFolding] Preserve inbounds when casting GEP indicesNikita Popov1-3/+5
This canonicalization just makes the implicit sext/trunc explicit, and does not affect the inbounds-ness of the GEP.
2023-02-27[ConstExpr] Avoid creation of select constant expressionsNikita Popov1-1/+1
These expressions will now only be created if explicitly requested in IR/bitcode (and by LowerTypeTests, which has a tricky to remove use). This is in preparation for removing these expressions entirely, but also fixes #60983 in the meantime.
2023-02-19Use APInt::getSignificantBits instead of APInt::getMinSignedBits (NFC)Kazu Hirata1-1/+1
Note that getMinSignedBits has been soft-deprecated in favor of getSignificantBits.
2023-02-19Use APInt::count{l,r}_{zero,one} (NFC)Kazu Hirata1-2/+2
2023-02-19Use APInt::popcount instead of APInt::countPopulation (NFC)Kazu Hirata1-1/+1
This is for consistency with the C++20-style bit manipulation functions in <bit>.
2023-02-15[ConstantFold] Check for constant global earlier (NFC)Nikita Popov1-14/+11
Check that the underlying object is a constant global with definitive initializer upfront, so we can skip the more expensive offset calculation logic if we can't perform the fold anyway.
2023-01-16[llvm][ADT] Replace uses of `makeMutableArrayRef` with deduction guidesJoe Loser1-1/+1
Similar to how `makeArrayRef` is deprecated in favor of deduction guides, do the same for `makeMutableArrayRef`. Once all of the places in-tree are using the deduction guides for `MutableArrayRef`, we can mark `makeMutableArrayRef` as deprecated. Differential Revision: https://reviews.llvm.org/D141814
2023-01-11[NFC] Use TypeSize::geFixedValue() instead of TypeSize::getFixedSize()Guillaume Chatelet1-3/+3
This change is one of a series to implement the discussion from https://reviews.llvm.org/D141134.
2023-01-06Revert D141134 "[NFC] Only expose getXXXSize functions in TypeSize"Guillaume Chatelet1-1/+1
The patch should be discussed further. This reverts commit dd56e1c92b0e6e6be249f2d2dd40894e0417223f.
2023-01-06[NFC] Only expose getXXXSize functions in TypeSizeGuillaume Chatelet1-1/+1
Currently 'TypeSize' exposes two functions that serve the same purpose: - getFixedSize / getFixedValue - getKnownMinSize / getKnownMinValue source : https://github.com/llvm/llvm-project/blob/bf82070ea465969e9ae86a31dfcbf94c2a7b4c4c/llvm/include/llvm/Support/TypeSize.h#L337-L338 This patch offers to remove one of the two and stick to a single function in the code base. Differential Revision: https://reviews.llvm.org/D141134
2023-01-05Move from llvm::makeArrayRef to ArrayRef deduction guides - llvm/ partserge-sans-paille1-5/+4
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-13ConstantFolding: Ignore output denorm mode for canonicalizeMatt Arsenault1-3/+4
Alive2 opt plugin is now happy with the test. Fixes issue 59245
2022-12-13ConstantFolding: Fix handling of canonicalize for ppc_fp128 0sMatt Arsenault1-2/+6
2022-12-12InstSimplify: Add basic folding of llvm.is.fpclass intrinsicMatt Arsenault1-0/+21
Copied from the existing llvm.amdgcn.class handling; eventually I will fold that to the generic intrinsic when legal. The tests should probably move into an instsimplify only test.
2022-12-05[IR] llvm::Optional => std::optionalFangrui Song1-3/+3
Many llvm/IR/* files have been migrated by other contributors. This migrates most remaining files.
2022-12-03FPEnv: convert Optional to std::optionalKrzysztof Parzyszek1-6/+6
2022-11-30ConstantFolding: Guard use of getFunctionDavid Stuttard1-1/+1
Add additional guards for a use of getFunction on an Instruction In some cases constanfFoldCanonicalize can be called with a cloned instruction that doesn't have a parent (or associated function), causing a seg fault. Differential Revision: https://reviews.llvm.org/D138642
2022-11-18ConstantFolding: Constant fold some canonicalizesMatt Arsenault1-1/+46
+/-0 is obviously foldable. Other non-special, non-subnormal values are also probably OK. For denormal values, check the calling function's denormal mode. For now, don't fold denormals to the input for IEEE mode because as far as I know the langref is still pretending LLVM's float isn't IEEE. Also folds undef to 0, although NaN may make more sense. Skips folding nans and infinities, although it should be OK to fold those in a future change.
2022-09-07[ConstantExpr] Don't create fneg expressionsNikita Popov1-1/+1
Don't create fneg expressions unless explicitly requested by IR or bitcode.
2022-08-20[EarlyCSE][ConstantFolding] do not constant fold atan2(+/-0.0, +/-0.0), part 2Sanjay Patel1-0/+5
Follow-up to 7f1262a322c0d80f3. That patch avoided removing the call, but it still allowed the constant-folded result. This makes the behavior consistent with 1-arg libm folding: if the call potentially raises an exception, then we just bail out. It seems likely that there are other corner-cases like this, but the tests are incomplete, so we have lived with these discrepancies for a long time. This was untested before the the constant folding was expanded in D127964.
2022-08-19[EarlyCSE][ConstantFolding] do not constant fold atan2(+/-0.0, +/-0.0)Sanjay Patel1-4/+5
These may raise an error (set errno) as discussed in the post-commit comments for D127964, so we can't fold away the call and potentially alter that behavior.
2022-08-11[Support] Remove Log2 workaround for Android API level < 18Fangrui Song1-2/+2
The function added by D9467 is unneeded. https://github.com/android/ndk/wiki/Changelog-r24 shows that the NDK has moved forward to at least a minimum target API of 19. Reviewed By: srhines Differential Revision: https://reviews.llvm.org/D131656
2022-08-10[ConstantFolding] Eliminate atan and atan2 callsMohammed Nurul Hoque1-0/+15
From the opengroup specifications, atan2 may fail if the result underflows and atan may fail if the argument is subnormal, but we assume that does not happen and eliminate the calls if we can constant fold the result at compile-time. Differential Revision: https://reviews.llvm.org/D127964
generated by cgit v1.1 at 2025-09-29 03:12:52 +0000