aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/IR/ConstantFold.cpp
AgeCommit message (Collapse)AuthorFilesLines
2021-12-28[ConstFold] Don't fold signed comparison of gep of globalNikita Popov1-4/+4
An inbounds GEP may still cross the sign boundary, so signed icmps cannot be folded (https://alive2.llvm.org/ce/z/XSgi4D). This was previously fixed for other folds in this function, but this one was missed.
2021-12-25[NFC] Method for evaluation of FCmpInst for constant operandsSerge Pavlov1-40/+2
New method `FCmpInst::compare` is added, which evaluates the given compare predicate for constant operands. Interface is made similar to `ICmpInst::compare`. Differential Revision: https://reviews.llvm.org/D116168
2021-12-08[llvm] Use range-based for loops (NFC)Kazu Hirata1-5/+4
2021-11-10[IR] In ConstantFoldShuffleVectorInstruction use zeroinitializer for splats of 0David Sherwood1-3/+7
When creating a splat of 0 for scalable vectors we tend to create them with using a combination of shufflevector and insertelement, i.e. shufflevector (<vscale x 4 x i32> insertelement (<vscale x 4 x i32> poison, i32 0, i32 0), <vscale x 4 x i32> poison, <vscale x 4 x i32> zeroinitializer) However, for the case of a zero splat we can actually just replace the above with zeroinitializer instead. This makes the IR a lot simpler and easier to read. I have changed ConstantFoldShuffleVectorInstruction to use zeroinitializer when creating a splat of integer 0 or FP +0.0 values. Differential Revision: https://reviews.llvm.org/D113394
2021-10-30[NFCI] Introduce `ICmpInst::compare()` and use it where appropriateRoman Lebedev1-13/+2
As noted in https://reviews.llvm.org/D90924#inline-1076197 apparently this is a pretty common pattern, let's not repeat it yet again, but have it in a common place. There may be some more places where it could be used, but these are the most obvious ones.
2021-10-04[APInt] Stop using soft-deprecated constructors and methods in llvm. NFC.Jay Foad1-2/+2
Stop using APInt constructors and methods that were soft-deprecated in D109483. This fixes all the uses I found in llvm, except for the APInt unit tests which should still test the deprecated methods. Differential Revision: https://reviews.llvm.org/D110807
2021-09-24[ConstantFold] ConstantFoldGetElementPtr - use APInt::isNegative() instead ↵Simon Pilgrim1-2/+2
of getSExtValue() to support big ints Fixes fuzz test: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39197
2021-09-09[APInt] Normalize naming on keep constructors / predicate methods.Chris Lattner1-1/+1
This renames the primary methods for creating a zero value to `getZero` instead of `getNullValue` and renames predicates like `isAllOnesValue` to simply `isAllOnes`. This achieves two things: 1) This starts standardizing predicates across the LLVM codebase, following (in this case) ConstantInt. The word "Value" doesn't convey anything of merit, and is missing in some of the other things. 2) Calling an integer "null" doesn't make any sense. The original sin here is mine and I've regretted it for years. This moves us to calling it "zero" instead, which is correct! APInt is widely used and I don't think anyone is keen to take massive source breakage on anything so core, at least not all in one go. As such, this doesn't actually delete any entrypoints, it "soft deprecates" them with a comment. Included in this patch are changes to a bunch of the codebase, but there are more. We should normalize SelectionDAG and other APIs as well, which would make the API change more mechanical. Differential Revision: https://reviews.llvm.org/D109483
2021-08-03[NFC][ConstantFold] Check getAggregateElement before getSplatValue callSenran Zhang1-1/+4
Constant::getSplatValue has O(N) time complexity in the worst case, where N is the # of elements in a vector. So we call Constant::getAggregateElement first and return earlier if possible to avoid unnecessary getSplatValue calls. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D107252
2021-07-31[ConstantFold] Get rid of special cases for sizeof etc.Eli Friedman1-241/+0
Target-dependent constant folding will fold these down to simple constants (or at least, expressions that don't involve a GEP). We don't need heroics to try to optimize the form of the expression before that happens. Fixes https://bugs.llvm.org/show_bug.cgi?id=51232 . Differential Revision: https://reviews.llvm.org/D107116
2021-07-23[ConstantFold] Fix GEP of GEP fold with opaque pointersNikita Popov1-2/+5
This was previously combining indices even though they operate on different types. For non-opaque pointers, the condition is automatically satisfied based on the pointer types being equal.
2021-07-23[ConstantFold] Extract GEP of GEP fold (NFCI)Nikita Popov1-85/+91
Move this fold into a separate function and clean up the control flow a bit.
2021-06-24[ConstantFold] Allow propagation of poison for and/or i1Juneyoung Lee1-8/+1
They were disallowed due to its bad interaction with select i1 -> and/or i1. The transformation is now disabled by D101191, so let's revive this.
2021-06-22[ConstantFold] Skip bitcast -> GEP transform for opaque pointersNikita Popov1-2/+3
Same as with the InstCombine transform, this is not possible for bitcasts involving opaque pointers, as GEP preserves opaqueness.
2021-06-10[InstSimplify] Add constant fold for extractelement + splat for scalable vectorsCaroline Concatto1-8/+4
This patch allows that scalable vector can fold extractelement and constant splat only when the lane index is lower than the minimum number of elements of the vector. Differential Revision: https://reviews.llvm.org/D103180
2021-05-31[OpaquePtr] Clean up some uses of Type::getPointerElementType()Arthur Eubanks1-2/+2
These depend on pointee types.
2021-05-13Reapply [ConstantFold] Fold more operations to poisonJuneyoung Lee1-30/+29
This was reverted to mitigate mitigate miscompiles caused by the logical and/or to bitwise and/or fold. Reapply it now that the underlying issue has been fixed by D101191. ----- This patch folds more operations to poison. Alive2 proof: https://alive2.llvm.org/ce/z/mxcb9G (it does not contain tests about div/rem because they fold to poison when raising UB) Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D92270
2021-03-08[ConstantFold] Handle icmp of global and null consistentlyNikita Popov1-1/+1
Return UGT rather than NE for icmp @g, null, which is slightly stronger. This is consistent with what we do for more complex folds. It is somewhat silly that @g ugt null does not get folded while (gep @g) ugt null does.
2021-03-08[ConstProp] Fix folding of pointer icmp with signed predicatesNikita Popov1-18/+10
While @g ugt null is always true (ignoring weak symbols), @g sgt null is not necessarily the case -- that would imply that it is forbidden to place globals in the high half of the address space.
2021-03-08[ConstantFold] allow folding icmp of null and constexprSanjay Patel1-1/+11
I noticed that we were not folding expressions like this: icmp ult (constexpr), null in https://llvm.org/PR49355, so we end up with extremely large icmp instructions as the constant expressions pile up on each other. There is no potential to mis-fold an unsigned boundary condition with a zero/null, so this is just falling through a crack in the pattern matching. The more general case of comparisons of non-zero constants and constexpr are more tricky and may require the datalayout to know how to cast to different types, etc. Negative tests verify that we are only changing a subset of potential patterns. Differential Revision: https://reviews.llvm.org/D98150
2021-02-19Patch by @wecing (Chenguang Wang).Tim Shen1-8/+30
The current getFoldedSizeOf() implementation uses naive recursion, which could be really slow when the input structure type is too complex. This issue was first brought up in http://llvm.org/bugs/show_bug.cgi?id=8281; this change fixes it by adding memoization. Differential Revision: https://reviews.llvm.org/D6594
2021-02-04Revert "[ConstantFold] Fold more operations to poison"Juneyoung Lee1-29/+30
This reverts commit 53040a968dc2ff20931661e55f05da2ef8b964a0 due to its bad interaction with select i1 -> and/or i1 transformation. This fixes: https://bugs.llvm.org/show_bug.cgi?id=49005 https://bugs.llvm.org/show_bug.cgi?id=48435
2021-01-06[Constant] Add containsPoisonElementJuneyoung Lee1-1/+1
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
2020-12-30[X86] Add x86_amx type for intel AMX.Luo, Yuanke1-1/+1
The x86_amx is used for AMX intrisics. <256 x i32> is bitcast to x86_amx when it is used by AMX intrinsics, and x86_amx is bitcast to <256 x i32> when it is used by load/store instruction. So amx intrinsics only operate on type x86_amx. It can help to separate amx intrinsics from llvm IR instructions (+-*/). Thank Craig for the idea. This patch depend on https://reviews.llvm.org/D87981. Differential Revision: https://reviews.llvm.org/D91927
2020-11-30[ConstantFold] Don't fold and/or i1 poison to poison (NFC)Juneyoung Lee1-1/+8
.. because it causes miscompilation when combined with select i1 -> and/or. It is the select fold which is incorrect; but it is costly to disable the fold, so hack this one. D92270
2020-11-29[ConstantFold] Fold more operations to poisonJuneyoung Lee1-30/+29
This patch folds more operations to poison. Alive2 proof: https://alive2.llvm.org/ce/z/mxcb9G (it does not contain tests about div/rem because they fold to poison when raising UB) Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D92270
2020-11-29[ConstantFold] Fold operations to poison if possibleJuneyoung Lee1-6/+36
This patch updates ConstantFold, so operations are folded into poison if possible. <alive2 proofs> casts: https://alive2.llvm.org/ce/z/WSj7rw binary operations (arithmetic): https://alive2.llvm.org/ce/z/_7dEyJ binary operations (bitwise): https://alive2.llvm.org/ce/z/cezjVN vector/aggregate operations: https://alive2.llvm.org/ce/z/BQ7hWz unary ops: https://alive2.llvm.org/ce/z/yBRs4q other ops: https://alive2.llvm.org/ce/z/iXbcFD Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D92203
2020-11-17[SVE] Take constant fold fast path for splatted vscale vectorsChristopher Tetreault1-5/+5
This should be a perfectly reasonable operation for scalable vectors. Currently, it only works for zeroinitializer values of ScalableVectorType, but the fundamental operation is sound and it should be possible to make it work for other splats Reviewed By: david-arm Differential Revision: https://reviews.llvm.org/D77442
2020-10-20[ConstantFold] Fold the comparison of bitcasted global valuesShimin Cui1-1/+7
This is to simplify icmp instructions in the form like: %cmp = icmp eq i32 (i8*, i8*)* bitcast (i32 (i32**, i32**)* @f32 to i32 %(i8*, i8*)), bitcast (i32 (i64**, i64**) @f64 to i32 (i8*, i8*)*) Here @f32 and @f64 are two functions. Differential Revision: https://reviews.llvm.org/D87850
2020-09-11[ConstantFold] Make areGlobalsPotentiallyEqual less aggressive.Eli Friedman1-1/+1
In particular, we shouldn't make assumptions about globals which are unnamed_addr: we can fold them together with other globals. Also while I'm here, use isInterposable() instead of trying to explicitly name all the different kinds of weak linkage. Fixes https://bugs.llvm.org/show_bug.cgi?id=47090 Differential Revision: https://reviews.llvm.org/D87123
2020-09-11[ConstantFold] Fold binary arithmetic on scalable vector splats.Eli Friedman1-19/+16
It's a nice simplification, and it confuses instcombine if we don't do it. Differential Revision: https://reviews.llvm.org/D87422
2020-08-28[SVE] Make ElementCount members privateDavid Sherwood1-5/+6
This patch changes ElementCount so that the Min and Scalable members are now private and can only be accessed via the get functions getKnownMinValue() and isScalable(). In addition I've added some other member functions for more commonly used operations. Hopefully this makes the class more useful and will reduce the need for calling getKnownMinValue(). Differential Revision: https://reviews.llvm.org/D86065
2020-08-19Revert "Revert "[NFC][llvm] Make the contructors of `ElementCount` private.""Mehdi Amini1-1/+2
Was reverted because MLIR/Flang builds were broken, these APIs have been fixed in the meantime.
2020-08-19Revert "[NFC][llvm] Make the contructors of `ElementCount` private."Mehdi Amini1-2/+1
This reverts commit 264afb9e6aebc98c353644dd0700bec808501cab. (and dependent 6b742cc48 and fc53bd610f) MLIR/Flang are broken.
2020-08-19[NFC][llvm] Make the contructors of `ElementCount` private.Francesco Petrogalli1-1/+2
Differential Revision: https://reviews.llvm.org/D86120
2020-08-13[ConstProp] Handle insertelement constantsArthur Eubanks1-0/+9
Previously ConstantFoldExtractElementInstruction() would only work with insertelement instructions, not contants. This properly handles insertelement constants as well. Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D85865
2020-08-12Recommit "[InstSimplify] Remove select ?, undef, X -> X and select ?, X, ↵Craig Topper1-2/+22
undef -> X transforms" and its follow up patches This recommits the following patches now that D85684 has landed 1cf6f210a2e [IR] Disable select ? C : undef -> C fold in ConstantFoldSelectInstruction unless we know C isn't poison. 469da663f2d [InstSimplify] Re-enable select ?, undef, X -> X transform when X is provably not poison 122b0640fc9 [InstSimplify] Don't fold vectors of partial undef in SimplifySelectInst if the non-undef element value might produce poison ac0af12ed2f [InstSimplify] Add test cases for opportunities to fold select ?, X, undef -> X when we can prove X isn't poison 9b1e95329af [InstSimplify] Remove select ?, undef, X -> X and select ?, X, undef -> X transforms
2020-07-15Revert "[InstSimplify] Remove select ?, undef, X -> X and select ?, X, undef ↵Craig Topper1-22/+2
-> X transforms" and subsequent patches This reverts most of the following patches due to reports of miscompiles. I've left the added test cases with comments updated to be FIXMEs. 1cf6f210a2e [IR] Disable select ? C : undef -> C fold in ConstantFoldSelectInstruction unless we know C isn't poison. 469da663f2d [InstSimplify] Re-enable select ?, undef, X -> X transform when X is provably not poison 122b0640fc9 [InstSimplify] Don't fold vectors of partial undef in SimplifySelectInst if the non-undef element value might produce poison ac0af12ed2f [InstSimplify] Add test cases for opportunities to fold select ?, X, undef -> X when we can prove X isn't poison 9b1e95329af [InstSimplify] Remove select ?, undef, X -> X and select ?, X, undef -> X transforms
2020-07-10[IR] Disable select ? C : undef -> C fold in ConstantFoldSelectInstruction ↵Craig Topper1-2/+22
unless we know C isn't poison. This matches the recent change to InstSimplify from D83440. Differential Revision: https://reviews.llvm.org/D83535
2020-06-25[SVE] Make ConstantFoldGetElementPtr work for scalable vectors of indicesDavid Sherwood1-8/+7
This patch fixes a compiler crash that was hit when trying to simplify the following code: getelementptr [2 x i64], [2 x i64]* null, i64 0, <vscale x 2 x i64> zeroinitializer For the case where we have a null pointer value like above, we just need to ensure we don't assume the indices are always fixed width. Differential Revision: https://reviews.llvm.org/D82183
2020-06-23Remove GlobalValue::getAlignment().Eli Friedman1-2/+2
This function is deceptive at best: it doesn't return what you'd expect. If you have an arbitrary GlobalValue and you want to determine the alignment of that pointer, Value::getPointerAlignment() returns the correct value. If you want the actual declared alignment of a function or variable, GlobalObject::getAlignment() returns that. This patch switches all the users of GlobalValue::getAlignment to an appropriate alternative. Differential Revision: https://reviews.llvm.org/D80368
2020-06-17[SVE] Eliminate bad VectorType::getNumElements() calls from ConstantFoldChristopher Tetreault1-33/+49
Summary: Assume all usages of this function are explicitly fixed-width operations and cast to FixedVectorType Reviewers: efriedma, sdesmalen, c-rhodes, majnemer, dblaikie Reviewed By: sdesmalen Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80262
2020-06-03[SVE] Eliminate calls to default-false VectorType::get() from IRChristopher Tetreault1-4/+4
Reviewers: efriedma, kmclaughlin, sdesmalen, dexonsmith, dblaikie Reviewed By: efriedma Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80261
2020-05-20Make Value::getPointerAlignment() return an Align, not a MaybeAlign.Eli Friedman1-2/+3
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-04-23[SVE] Remove calls to isScalable from IRChristopher Tetreault1-9/+7
Reviewers: efriedma, sdesmalen, dexonsmith, dblaikie Reviewed By: sdesmalen Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77691
2020-04-14[SVE] Remove calls to getBitWidth from IRChristopher Tetreault1-1/+2
Reviewers: efriedma, sdesmalen, RKSimon, majnemer Reviewed By: majnemer Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77897
2020-04-10Clean up usages of asserting vector getters in TypeChristopher Tetreault1-36/+44
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: dexonsmith, sdesmalen, efriedma Reviewed By: efriedma Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77276
2020-04-06Remove SequentialType from the type heirarchy.Eli Friedman1-18/+7
Now that we have scalable vectors, there's a distinction that isn't getting captured in the original SequentialType: some vectors don't have a known element count, so counting the number of elements doesn't make sense. In some cases, there's a better way to express the commonality using other methods. If we're dealing with GEPs, there's GEP methods; if we're dealing with a ConstantDataSequential, we can query its element type directly. In the relatively few remaining cases, I just decided to write out the type checks. We're talking about relatively few places, and I think the abstraction doesn't really carry its weight. (See thread "[RFC] Refactor class hierarchy of VectorType in the IR" on llvmdev.) Differential Revision: https://reviews.llvm.org/D75661
2020-03-31Remove "mask" operand from shufflevector.Eli Friedman1-12/+11
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-2/+42
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
generated by cgit v1.1 at 2025-10-14 18:58:21 +0000