aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Analysis/ConstantFolding.cpp
AgeCommit message (Collapse)AuthorFilesLines
2016-08-25Fix some Clang-tidy modernize-use-using and Include What You Use warnings; ↵Eugene Zelenko1-6/+15
other minor fixes. Differential revision: https://reviews.llvm.org/D23861 llvm-svn: 279695
2016-08-05[ConstantFolding] Don't create illegal (non-integral) inttoptrsSanjoy Das1-3/+4
Reviewers: majnemer, arsenm Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D23182 llvm-svn: 277854
2016-07-29[ConstantFolding] Handle bitcasts of undef fp vector elementsDavid Majnemer1-1/+1
We used the wrong type for constructing a zero vector element which led to type mismatches. This fixes PR28771. llvm-svn: 277197
2016-07-29[ConstantFolding] Fold bitcasts of vectors w/ undef elementsDavid Majnemer1-2/+11
An undef vector element can be treated as if it had any value. Folding such a vector element to 0 in a bitcast can open up further folding opportunities. llvm-svn: 277104
2016-07-29[ConstantFolding] Remove an unused ConstantFoldInstOperands overloadDavid Majnemer1-14/+5
No functional change is intended. llvm-svn: 277101
2016-07-29[ConstantFolding] Use ConstantExpr::getWithOperandsDavid Majnemer1-0/+3
ConstantExpr::getWithOperands does much of the hard work that ConstantFoldInstOperandsImpl tries to do but more completely. This lets us fold ExtractValue/InsertValue expressions. llvm-svn: 277100
2016-07-29[ConstnatFolding] Teach the folder how to fold ConstantVectorDavid Majnemer1-57/+60
A ConstantVector can have ConstantExpr operands and vice versa. However, the folder had no ability to fold ConstantVectors which, in some cases, was an optimization barrier. Instead, rephrase the folder in terms of Constants instead of ConstantExprs and teach callers how to deal with failure. llvm-svn: 277099
2016-07-28[ConstantFolding] Don't bail on folding if ConstantFoldConstantExpression failsDavid Majnemer1-19/+23
When folding an expression, we run ConstantFoldConstantExpression on each operand of that expression. However, ConstantFoldConstantExpression can fail and retur nullptr. Previously, we would bail on further refining the expression. Instead, use the original operand and see if we can refine a later operand. llvm-svn: 276959
2016-07-27[ConstantFolding] Correctly handle failures in ↵David Majnemer1-4/+13
ConstantFoldConstantExpressionImpl Failures in ConstantFoldConstantExpressionImpl were ignored causing crashes down the line. This fixes PR28725. llvm-svn: 276827
2016-07-19[X86][SSE] Reimplement SSE fp2si conversion intrinsics instead of using ↵Simon Pilgrim1-9/+10
generic IR D20859 and D20860 attempted to replace the SSE (V)CVTTPS2DQ and VCVTTPD2DQ truncating conversions with generic IR instead. It turns out that the behaviour of these intrinsics is different enough from generic IR that this will cause problems, INF/NAN/out of range values are guaranteed to result in a 0x80000000 value - which plays havoc with constant folding which converts them to either zero or UNDEF. This is also an issue with the scalar implementations (which were already generic IR and what I was trying to match). This patch changes both scalar and packed versions back to using x86-specific builtins. It also deals with the other scalar conversion cases that are runtime rounding mode dependent and can have similar issues with constant folding. A companion clang patch is at D22105 Differential Revision: https://reviews.llvm.org/D22106 llvm-svn: 275981
2016-07-14Simplify llvm.masked.load w/ undef masksDavid Majnemer1-14/+21
We can always pick the passthru value if the mask is undef: we are permitted to treat the mask as-if it were filled with zeros. llvm-svn: 275379
2016-07-14[ConstantFolding] Fold masked loadsDavid Majnemer1-1/+36
We can constant fold a masked load if the operands are appropriately constant. Differential Revision: http://reviews.llvm.org/D22324 llvm-svn: 275352
2016-07-13[ConstantFolding] Extend FoldReinterpretLoadFromConstPtr to handle negative ↵David Majnemer1-10/+20
offsets Treat loads which clip before the start of a global initializer the same way we treat clipping beyond the end of the initializer: use zeros. llvm-svn: 275345
2016-07-13[ConstantFolding] Use sdiv_ovDavid Majnemer1-4/+4
This is a simplification, there should be no functional change. llvm-svn: 275273
2016-07-13[ConstantFolding] Don't treat negative GEP offsets as positiveDavid Majnemer1-4/+7
GEP offsets are signed, don't treat them as huge positive numbers. llvm-svn: 275251
2016-07-13[ConstantFolding] CleanupsDavid Majnemer1-67/+66
No functional change is intended, just a minor cleanup. llvm-svn: 275249
2016-07-13[IR] Make getIndexedOffsetInType return a signed resultDavid Majnemer1-1/+1
A GEPed offset can go negative, the result of getIndexedOffsetInType should according be a signed type. llvm-svn: 275246
2016-06-27[ConstantFolding] Fix bitcast vector of i1.Igor Breger1-1/+1
Differential Revision: http://reviews.llvm.org/D21735 llvm-svn: 273845
2016-06-21Replace silly uses of 'signed' with 'int'David Majnemer1-7/+6
llvm-svn: 273244
2016-05-04[ConstantFolding, ValueTracking] Fold constants involving bitcasts of ↵David Majnemer1-7/+10
ConstantVector We assumed that ConstantVectors would be rather uninteresting from the perspective of analysis. However, this is not the case due to a quirk of how LLVM handles vectors of i1. Vectors of i1 are not ConstantDataVectors like vectors of i8, i16, i32 or i64 because i1's SizeInBits differs from it's StoreSizeInBytes. This leads to it being categorized as a ConstantVector instead of a ConstantDataVector. Instead, treat ConstantVector more uniformly. This fixes PR27591. llvm-svn: 268479
2016-04-22CodeGen: Use PLT relocations for relative references to unnamed_addr functions.Peter Collingbourne1-2/+6
The relative vtable ABI (PR26723) needs PLT relocations to refer to virtual functions defined in other DSOs. The unnamed_addr attribute means that the function's address is not significant, so we're allowed to substitute it with the address of a PLT entry. Also includes a bonus feature: addends for COFF image-relative references. Differential Revision: http://reviews.llvm.org/D17938 llvm-svn: 267211
2016-04-08Propagate Undef in llvm.cos IntrinsicSanjoy Das1-0/+5
Summary: The llvm cos intrinsic currently does not propagate undef's. This change transforms cos(undef) to null value or 0. There are 2 test cases added as well. Patch by Anna Thomas! Reviewers: sanjoy Subscribers: majnemer, llvm-commits Differential Revision: http://reviews.llvm.org/D18863 llvm-svn: 265825
2016-04-08Don't IPO over functions that can be de-refinedSanjoy Das1-1/+1
Summary: Fixes PR26774. If you're aware of the issue, feel free to skip the "Motivation" section and jump directly to "This patch". Motivation: I define "refinement" as discarding behaviors from a program that the optimizer has license to discard. So transforming: ``` void f(unsigned x) { unsigned t = 5 / x; (void)t; } ``` to ``` void f(unsigned x) { } ``` is refinement, since the behavior went from "if x == 0 then undefined else nothing" to "nothing" (the optimizer has license to discard undefined behavior). Refinement is a fundamental aspect of many mid-level optimizations done by LLVM. For instance, transforming `x == (x + 1)` to `false` also involves refinement since the expression's value went from "if x is `undef` then { `true` or `false` } else { `false` }" to "`false`" (by definition, the optimizer has license to fold `undef` to any non-`undef` value). Unfortunately, refinement implies that the optimizer cannot assume that the implementation of a function it can see has all of the behavior an unoptimized or a differently optimized version of the same function can have. This is a problem for functions with comdat linkage, where a function can be replaced by an unoptimized or a differently optimized version of the same source level function. For instance, FunctionAttrs cannot assume a comdat function is actually `readnone` even if it does not have any loads or stores in it; since there may have been loads and stores in the "original function" that were refined out in the currently visible variant, and at the link step the linker may in fact choose an implementation with a load or a store. As an example, consider a function that does two atomic loads from the same memory location, and writes to memory only if the two values are not equal. The optimizer is allowed to refine this function by first CSE'ing the two loads, and the folding the comparision to always report that the two values are equal. Such a refined variant will look like it is `readonly`. However, the unoptimized version of the function can still write to memory (since the two loads //can// result in different values), and selecting the unoptimized version at link time will retroactively invalidate transforms we may have done under the assumption that the function does not write to memory. Note: this is not just a problem with atomics or with linking differently optimized object files. See PR26774 for more realistic examples that involved neither. This patch: This change introduces a new set of linkage types, predicated as `GlobalValue::mayBeDerefined` that returns true if the linkage type allows a function to be replaced by a differently optimized variant at link time. It then changes a set of IPO passes to bail out if they see such a function. Reviewers: chandlerc, hfinkel, dexonsmith, joker.eph, rnk Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D18634 llvm-svn: 265762
2016-03-28Fix Clang-tidy modernize-deprecated-headers warnings in some files; other ↵Eugene Zelenko1-61/+63
minor fixes. Differential revision: http://reviews.llvm.org/D18469 llvm-svn: 264598
2016-03-21Implement constant folding for bitreverseMatt Arsenault1-0/+3
llvm-svn: 263945
2016-03-14Re-add ConstantFoldInstOperands form taking opcode and return type.Manuel Jacob1-4/+13
Summary: This form was replaced by a form taking an instruction instead of opcode and return type in r258391. After committing this change (and some depending, follow-up changes) it turned out in the review thread to be controversial. The discussion didn't come to a conclusion yet. I'm re-adding the old form to fix the API regression and to provide a better base for discussion, possibly on llvm-dev. A difference to the original function is that it can't be called with GEPs (similarly to how it was already the case for compares). In order to support opaque pointers in the future, folding GEPs needs to be passed the source element type, which is not possible with the current API. Reviewers: dberlin, reames Subscribers: dblaikie, eddyb Differential Revision: http://reviews.llvm.org/D17901 llvm-svn: 263501
2016-03-13ConstantFoldInstruction: avoid wasted calls to ConstantFoldConstantExpressionFiona Glaser1-5/+5
Check to see if all operands are constant before calling simplify on them so that we don't perform wasted simplifications. llvm-svn: 263374
2016-02-13[ConstantFolding] Reduce APInt and APFloat copying.Benjamin Kramer1-1/+1
llvm-svn: 260826
2016-01-23Remove duplicate documentation in ConstantFolding.cpp. NFC.Manuel Jacob1-22/+0
The documentation for these functions is already present in the header file. llvm-svn: 258649
2016-01-22[opaque pointer types] [NFC] DataLayout::getIndexedOffset: take source ↵Eduard Burtescu1-3/+4
element type instead of pointer type and rename to getIndexedOffsetInType. Summary: Reviewers: mjacob, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16282 llvm-svn: 258478
2016-01-22[opaque pointer types] [NFC] Add an explicit type argument to ↵Eduard Burtescu1-21/+21
ConstantFoldLoadFromConstPtr. Reviewers: mjacob, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16418 llvm-svn: 258472
2016-01-21[opaque pointer types] [NFC] Take advantage of get{Source,Result}ElementType ↵Eduard Burtescu1-45/+58
when folding GEPs. Summary: Reviewers: mjacob, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16302 llvm-svn: 258456
2016-01-21Undo r258163 "Move part of an if condition into an assertion. NFC."Manuel Jacob1-2/+2
This undoes the change made in r258163. The assertion fails if `Ptr` is of a vector type. The previous code doesn't look completely correct either, so I'll investigate this more. llvm-svn: 258411
2016-01-21Change ConstantFoldInstOperands to take Instruction instead of opcode and ↵Manuel Jacob1-48/+56
type. NFC. Summary: The previous form, taking opcode and type, is moved to an internal helper and the new form, taking an instruction, is a wrapper around this helper. Although this is a slight cleanup on its own, the main motivation is to refactor the constant folding API to ease migration to opaque pointers. This will be follow-up work. Reviewers: eddyb Subscribers: dblaikie, llvm-commits Differential Revision: http://reviews.llvm.org/D16383 llvm-svn: 258391
2016-01-21Introduce ConstantFoldCastOperand function and migrate some callers of ↵Manuel Jacob1-52/+64
ConstantFoldInstOperands to use it. NFC. Summary: Although this is a slight cleanup on its own, the main motivation is to refactor the constant folding API to ease migration to opaque pointers. This will be follow-up work. Reviewers: eddyb Subscribers: zzheng, dblaikie, llvm-commits Differential Revision: http://reviews.llvm.org/D16380 llvm-svn: 258390
2016-01-21Introduce ConstantFoldBinaryOpOperands function and migrate some callers of ↵Manuel Jacob1-10/+13
ConstantFoldInstOperands to use it. NFC. Summary: Although this is a slight cleanup on its own, the main motivation is to refactor the constant folding API to ease migration to opaque pointers. This will be follow-up work. Reviewers: eddyb Subscribers: dblaikie, llvm-commits Differential Revision: http://reviews.llvm.org/D16378 llvm-svn: 258389
2016-01-19Move part of an if condition into an assertion. NFC.Manuel Jacob1-2/+2
llvm-svn: 258163
2015-08-27Enable constant propagation for more math functionsErik Schnetter1-37/+55
Constant propagation for single precision math functions (such as tanf) is already working, but was not enabled. This patch enables these for many single-precision functions, and adds respective test cases. Newly handled functions: acosf asinf atanf atan2f ceilf coshf expf exp2f fabsf floorf fmodf logf log10f powf sinhf tanf tanhf llvm-svn: 246194
2015-08-27Revert 246186; still breaks on some systemsErik Schnetter1-55/+37
llvm-svn: 246191
2015-08-27Enable constant propagation for more math functionsErik Schnetter1-37/+55
Constant propagation for single precision math functions (such as tanf) is already working, but was not enabled. This patch enables these for many single-precision functions, and adds respective test cases. Newly handled functions: acosf asinf atanf atan2f ceilf coshf expf exp2f fabsf floorf fmodf logf log10f powf sinhf tanf tanhf llvm-svn: 246186
2015-08-27Revert r246158 since it breaks LLVM.Transforms/ConstProp.calls.llErik Schnetter1-55/+37
llvm-svn: 246166
2015-08-27Enable constant propagation for more math functionsErik Schnetter1-37/+55
Constant propagation for single precision math functions (such as tanf) is already working, but was not enabled. This patch enables these for many single-precision functions, and adds respective test cases. Newly handled functions: acosf asinf atanf atan2f ceilf coshf expf exp2f fabsf floorf fmodf logf log10f powf sinhf tanf tanhf llvm-svn: 246158
2015-07-27Fix assert when inlining a constantexpr addrspacecastMatt Arsenault1-2/+1
The pointer size of the addrspacecasted pointer might not have matched, so this would have hit an assert in accumulateConstantOffset. I think this was here to allow constant folding of a load of an addrspacecasted constant. Accumulating the offset through the addrspacecast doesn't make much sense, so something else is necessary to allow folding the load through this cast. llvm-svn: 243300
2015-07-22[ConstantFolding] Support folding loads from a GlobalAliasDavid Majnemer1-0/+4
The MSVC ABI requires that we generate an alias for the vtable which means looking through a GlobalAlias which cannot be overridden improves our ability to devirtualize. Found while investigating PR20801. Patch by Andrew Zhogin! Differential Revision: http://reviews.llvm.org/D11306 llvm-svn: 242955
2015-07-21Constfold trunc,rint,nearbyint,ceil and floor using APFloatKarthik Bhat1-4/+33
A patch by Chakshu Grover! This patch allows constfolding of trunc,rint,nearbyint,ceil and floor intrinsics using APFloat class. Differential Revision: http://reviews.llvm.org/D11144 llvm-svn: 242763
2015-07-08Allow constfolding of llvm.sin.* and llvm.cos.* intrinsicsKarthik Bhat1-0/+6
This patch const folds llvm.sin.* and llvm.cos.* intrinsics whenever feasible. Differential Revision: http://reviews.llvm.org/D10836 llvm-svn: 241665
2015-05-14[ConstantFolding] Fix wrong folding of intrinsic 'convert.from.fp16'.Andrea Di Biagio1-2/+2
Function 'ConstantFoldScalarCall' (in ConstantFolding.cpp) works under the wrong assumption that a call to 'convert.from.fp16' returns a value of type 'float'. However, intrinsic 'convert.from.fp16' can be overloaded; for example, we can call 'convert.from.fp16.f64' to convert from half to double; etc. Before this patch, the following example would have triggered an assertion failure in opt (with -constprop): ``` define double @foo() { entry: %0 = call double @llvm.convert.from.fp16.f64(i16 0) ret double %0 } ``` This patch fixes the problem in ConstantFolding.cpp. When folding a call to convert.from.fp16, we perform a different kind of conversion based on the call return type. Added test 'Transform/ConstProp/convert-from-fp16.ll'. Differential Revision: http://reviews.llvm.org/D9771 llvm-svn: 237377
2015-05-12Convert PHI getIncomingValue() to foreach over incoming_values(). NFC.Pete Cooper1-2/+1
We already had a method to iterate over all the incoming values of a PHI. This just changes all eligible code to use it. Ineligible code included anything which cared about the index, or was also trying to get the i'th incoming BB. llvm-svn: 237169
2015-05-07Added support for building against Android API-9 SDKVince Harron1-1/+1
Created an abstraction for log2, llvm::Log2 in Support/MathExtras.h Hid Android problems inside of it Differential Revision: http://reviews.llvm.org/D9467 llvm-svn: 236680
2015-04-02[opaque pointer type] API migration for GEP constant factoriesDavid Blaikie1-9/+11
Require the pointee type to be passed explicitly and assert that it is correct. For now it's possible to pass nullptr here (and I've done so in a few places in this patch) but eventually that will be disallowed once all clients have been updated or removed. It'll be a long road to get all the way there... but if you have the cahnce to update your callers to pass the type explicitly without depending on a pointer's element type, that would be a good thing to do soon and a necessary thing to do eventually. llvm-svn: 233938
generated by cgit v1.1 at 2025-10-16 18:59:36 +0000