summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/ConstantFolding.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [opaque pointer types] [NFC] DataLayout::getIndexedOffset: take source ↵Eduard Burtescu2016-01-221-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
* [opaque pointer types] [NFC] Add an explicit type argument to ↵Eduard Burtescu2016-01-221-21/+21
| | | | | | | | | | | | ConstantFoldLoadFromConstPtr. Reviewers: mjacob, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16418 llvm-svn: 258472
* [opaque pointer types] [NFC] Take advantage of get{Source,Result}ElementType ↵Eduard Burtescu2016-01-211-45/+58
| | | | | | | | | | | | | | when folding GEPs. Summary: Reviewers: mjacob, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16302 llvm-svn: 258456
* Undo r258163 "Move part of an if condition into an assertion. NFC."Manuel Jacob2016-01-211-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
* Change ConstantFoldInstOperands to take Instruction instead of opcode and ↵Manuel Jacob2016-01-211-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
* Introduce ConstantFoldCastOperand function and migrate some callers of ↵Manuel Jacob2016-01-211-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
* Introduce ConstantFoldBinaryOpOperands function and migrate some callers of ↵Manuel Jacob2016-01-211-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
* Move part of an if condition into an assertion. NFC.Manuel Jacob2016-01-191-2/+2
| | | | llvm-svn: 258163
* Enable constant propagation for more math functionsErik Schnetter2015-08-271-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
* Revert 246186; still breaks on some systemsErik Schnetter2015-08-271-55/+37
| | | | llvm-svn: 246191
* Enable constant propagation for more math functionsErik Schnetter2015-08-271-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
* Revert r246158 since it breaks LLVM.Transforms/ConstProp.calls.llErik Schnetter2015-08-271-55/+37
| | | | llvm-svn: 246166
* Enable constant propagation for more math functionsErik Schnetter2015-08-271-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
* Fix assert when inlining a constantexpr addrspacecastMatt Arsenault2015-07-271-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
* [ConstantFolding] Support folding loads from a GlobalAliasDavid Majnemer2015-07-221-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
* Constfold trunc,rint,nearbyint,ceil and floor using APFloatKarthik Bhat2015-07-211-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
* Allow constfolding of llvm.sin.* and llvm.cos.* intrinsicsKarthik Bhat2015-07-081-0/+6
| | | | | | | | This patch const folds llvm.sin.* and llvm.cos.* intrinsics whenever feasible. Differential Revision: http://reviews.llvm.org/D10836 llvm-svn: 241665
* [ConstantFolding] Fix wrong folding of intrinsic 'convert.from.fp16'.Andrea Di Biagio2015-05-141-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
* Convert PHI getIncomingValue() to foreach over incoming_values(). NFC.Pete Cooper2015-05-121-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
* Added support for building against Android API-9 SDKVince Harron2015-05-071-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
* [opaque pointer type] API migration for GEP constant factoriesDavid Blaikie2015-04-021-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
* [opaque pointer type] Change GetElementPtrInst::getIndexedType to take the ↵David Blaikie2015-03-301-2/+3
| | | | | | | | | | pointee type This pushes the use of PointerType::getElementType up into several callers - I'll essentially just have to keep pushing that up the stack until I can eliminate every call to it... llvm-svn: 233604
* DataLayout is mandatory, update the API to reflect it with references.Mehdi Amini2015-03-101-133/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Now that the DataLayout is a mandatory part of the module, let's start cleaning the codebase. This patch is a first attempt at doing that. This patch is not exactly NFC as for instance some places were passing a nullptr instead of the DataLayout, possibly just because there was a default value on the DataLayout argument to many functions in the API. Even though it is not purely NFC, there is no change in the validation. I turned as many pointer to DataLayout to references, this helped figuring out all the places where a nullptr could come up. I had initially a local version of this patch broken into over 30 independant, commits but some later commit were cleaning the API and touching part of the code modified in the previous commits, so it seemed cleaner without the intermediate state. Test Plan: Reviewers: echristo Subscribers: llvm-commits From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231740
* Drop the hacks used for partial C99 math libraries.Benjamin Kramer2015-03-091-10/+0
| | | | | | All supported platforms have half-way decent C99 support. llvm-svn: 231679
* [PM] Move TargetLibraryInfo into the Analysis library.Chandler Carruth2015-01-151-1/+1
| | | | | | | | | | | | | | | | While the term "Target" is in the name, it doesn't really have to do with the LLVM Target library -- this isn't an abstraction which LLVM targets generally need to implement or extend. It has much more to do with modeling the various runtime libraries on different OSes and with different runtime environments. The "target" in this sense is the more general sense of a target of cross compilation. This is in preparation for porting this analysis to the new pass manager. No functionality changed, and updates inbound for Clang and Polly. llvm-svn: 226078
* Update SetVector to rely on the underlying set's insert to return a ↵David Blaikie2014-11-191-1/+1
| | | | | | | | | | | | | pair<iterator, bool> This is to be consistent with StringSet and ultimately with the standard library's associative container insert function. This lead to updating SmallSet::insert to return pair<iterator, bool>, and then to update SmallPtrSet::insert to return pair<iterator, bool>, and then to update all the existing users of those functions... llvm-svn: 222334
* [InstSimplify] Support constant folding to vector of pointersBruno Cardoso Lopes2014-10-221-2/+12
| | | | | | | | | | | | | | | | | | | ConstantFolding crashes when trying to InstSimplify the following load: @a = private unnamed_addr constant %mst { i8* inttoptr (i64 -1 to i8*), i8* inttoptr (i64 -1 to i8*) }, align 8 %x = load <2 x i8*>* bitcast (%mst* @a to <2 x i8*>*), align 8 This patch fix this by adding support to this type of folding: %x = load <2 x i8*>* bitcast (%mst* @a to <2 x i8*>*), align 8 ==> gets folded to: %x = <2 x i8*> <i8* inttoptr (i64 -1 to i8*), i8* inttoptr (i64 -1 to i8*)> llvm-svn: 220380
* Add minnum / maxnum intrinsicsMatt Arsenault2014-10-211-0/+15
| | | | | | | | | | | | These are named following the IEEE-754 names for these functions, rather than the libm fmin / fmax to avoid possible ambiguities. Some languages may implement something resembling fmin / fmax which return NaN if either operand is to propagate errors. These implement the IEEE-754 semantics of returning the other operand if either is a NaN representing missing data. llvm-svn: 220341
* Remove duplicate function names from comments. NFC.Sanjay Patel2014-10-021-43/+35
| | | | llvm-svn: 218875
* Make the sqrt intrinsic return undef for a negative input.Sanjay Patel2014-10-011-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | As discussed here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140609/220598.html And again here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-September/077168.html The sqrt of a negative number when using the llvm intrinsic is undefined. We should return undef rather than 0.0 to match the definition in the LLVM IR lang ref. This change should not affect any code that isn't using "no-nans-fp-math"; ie, no-nans is a requirement for generating the llvm intrinsic in place of a sqrt function call. Unfortunately, the behavior introduced by this patch will not match current gcc, xlc, icc, and possibly other compilers. The current clang/llvm behavior of returning 0.0 doesn't either. We knowingly approve of this difference with the other compilers in an attempt to flag code that is invoking undefined behavior. A front-end warning should also try to convince the user that the program will fail: http://llvm.org/bugs/show_bug.cgi?id=21093 Differential Revision: http://reviews.llvm.org/D5527 llvm-svn: 218803
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-211-1/+1
| | | | | | needing to mention the size. llvm-svn: 216158
* Revert "Repace SmallPtrSet with SmallPtrSetImpl in function arguments to ↵Craig Topper2014-08-181-1/+1
| | | | | | | | avoid needing to mention the size." Getting a weird buildbot failure that I need to investigate. llvm-svn: 215870
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-171-1/+1
| | | | | | needing to mention the size. llvm-svn: 215868
* Look through addrspacecast in IsConstantOffsetFromGlobalMatt Arsenault2014-07-141-1/+2
| | | | llvm-svn: 213000
* Remove old fenv.h workaround for a historic clang driver bugAlp Toker2014-06-091-9/+2
| | | | | | | | | | | Tested and works fine with clang using libstdc++. All indications are that this was fixed some time ago and isn't a problem with any clang version we support. I've added a note in PR6907 which is still open for some reason. llvm-svn: 210485
* Fold FEnv.h into the implementationAlp Toker2014-06-091-7/+41
| | | | | | | | | | | | | | | | | | Support headers shouldn't use config.h definitions, and they should never be undefined like this. ConstantFolding.cpp was the only user of this facility and already includes config.h for other math features, so it makes sense to move the checks there at point of use. (The implicit config.h was also quite dangerous -- removing the FEnv.h include would have silently disabled math constant folding without causing any tests to fail. Need to investigate -Wundef once the cleanup is done.) This eliminates the last config.h include from LLVM headers, paving the way for more consistent configuration checks. llvm-svn: 210483
* Add a Constant version of stripPointerCasts.Rafael Espindola2014-06-041-1/+1
| | | | | | Thanks to rnk for the suggestion. llvm-svn: 210205
* Teach the constant folder to look through bitcast constant expressionsChandler Carruth2014-05-151-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | much more effectively when trying to constant fold a load of a constant. Previously, we only handled bitcasts by trying to find a totally generic byte representation of the constant and use that. Now, we look through the bitcast to see what constant we might fold the load into, and then try to form a constant expression cast of the found value that would be equivalent to loading the value. You might wonder why on earth this actually matters. Well, turns out that the Itanium ABI causes us to create a single array for a vtable where the first elements are virtual base offsets, followed by the virtual function pointers. Because the array is homogenous the element type is consistently i8* and we inttoptr the virtual base offsets into the initial elements. Then constructors bitcast these pointers to i64 pointers prior to loading them. Boom, no more constant folding of virtual base offsets. This is the first fix to LLVM to address the *insane* performance Eric Niebler discovered with Clang on his range comprehensions[1]. There is more to come though, this doesn't *really* fix the problem fully. [1]: http://ericniebler.com/2014/04/27/range-comprehensions/ llvm-svn: 208856
* Rename ComputeMaskedBits to computeKnownBits. "Masked" has beenJay Foad2014-05-141-2/+2
| | | | | | inappropriate since it lost its Mask parameter in r154011. llvm-svn: 208811
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-151-53/+53
| | | | | | instead of comparing to nullptr. llvm-svn: 206243
* Allow constant folding of ceil function whenever feasibleKarthik Bhat2014-03-241-0/+3
| | | | llvm-svn: 204583
* Allow constant folding of round function whenever feasibleKarthik Bhat2014-03-071-0/+7
| | | | llvm-svn: 203198
* Allow constant folding of copysignKarthik Bhat2014-03-061-0/+7
| | | | llvm-svn: 203076
* ConstantFolding: Also fold the vector overloads of our math intrinsics.Benjamin Kramer2014-03-051-34/+73
| | | | llvm-svn: 202997
* Allow constant folding of fma and fmuladdMatt Arsenault2014-03-051-0/+27
| | | | llvm-svn: 202914
* Fix duplicate code in ConstantFoldingMatt Arsenault2014-03-051-54/+33
| | | | llvm-svn: 202913
* [Modules] Move GetElementPtrTypeIterator into the IR library. As itsChandler Carruth2014-03-041-1/+1
| | | | | | | | | name might indicate, it is an iterator over the types in an instruction in the IR.... You see where this is going. Another step of modularizing the support library. llvm-svn: 202815
* Add addrspacecast instruction.Matt Arsenault2013-11-151-5/+7
| | | | | | Patch by Michele Scandale! llvm-svn: 194760
* Fix another constant folding address space place I missed.Matt Arsenault2013-11-041-12/+19
| | | | | | This fixes an assertion failure with a different sized address space. llvm-svn: 194014
* Fix a constant folding address space place I missed.Matt Arsenault2013-09-171-3/+4
| | | | | | | | If address space 0 was smaller than the address space in a constant inttoptr/ptrtoint pair, the wrong mask size would be used. llvm-svn: 190899
OpenPOWER on IntegriCloud