summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/ConstantFolding.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [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
* Move variable under condition where it is usedMatt Arsenault2013-09-121-1/+2
| | | | llvm-svn: 190567
* Teach ConstantFolding about pointer address spacesMatt Arsenault2013-08-201-33/+54
| | | | llvm-svn: 188831
* Slightly simplify code with helper functionsMatt Arsenault2013-08-121-14/+16
| | | | | | | e.g. Use Ty->getPointerElementType() instead of cast<PointerType>(Ty)->getElementType() llvm-svn: 188223
* Add some braces, and spaces around operatorsMatt Arsenault2013-08-121-26/+42
| | | | llvm-svn: 188219
* ConstantFolding: ComputeMaskedBits wants the scalar size for vectors.Benjamin Kramer2013-04-191-1/+1
| | | | | | Fixes PR15791. llvm-svn: 179859
* Fix a scalability issue with complex ConstantExprs.Benjamin Kramer2013-04-131-12/+24
| | | | | | | | | | | | | | | This is basically the same fix in three different places. We use a set to avoid walking the whole tree of a big ConstantExprs multiple times. For example: (select cmp, (add big_expr 1), (add big_expr 2)) We don't want to visit big_expr twice here, it may consist of thousands of nodes. The testcase exercises this by creating an insanely large ConstantExprs out of a loop. It's questionable if the optimizer should ever create those, but this can be triggered with real C code. Fixes PR15714. llvm-svn: 179458
* Constant fold vector bitcasts of halves similarly to how floats and doubles ↵Michael Ilseman2013-02-261-6/+8
| | | | | | are folded. Test case included. llvm-svn: 176131
* Formatting.Chad Rosier2013-02-201-2/+1
| | | | llvm-svn: 175692
* Teach the DataLayout aware constant folder to be much more aggressive towardsNick Lewycky2013-02-141-8/+30
| | | | | | 'and' instructions. This is a pattern that shows up a lot in ubsan binaries. llvm-svn: 175128
* Conditionalize constant folding of math intrinsics on the availability of an ↵Owen Anderson2013-02-071-0/+10
| | | | | | implementation on the host. This is a little bit unfortunate, but until someone decides to implement a full libm for APFloat, we don't have a better way to get this functionality. llvm-svn: 174561
* Signficantly generalize our ability to constant fold floating point ↵Owen Anderson2013-02-061-14/+88
| | | | | | intrinsics, including ones on half types. llvm-svn: 174555
* ConstantFolding: Fix a crash when encoutering a truncating inttoptr.Benjamin Kramer2013-02-051-3/+7
| | | | | | This was introduced in r173293. llvm-svn: 174424
* use GEP::accumulateConstantOffset() to replace custom written code to ↵Nuno Lopes2013-02-031-27/+2
| | | | | | compute GEP offset llvm-svn: 174279
* ConstantFolding: Add a missing folding that leads to a miscompile.Benjamin Kramer2013-01-241-4/+4
| | | | | | | | | | We use constant folding to see if an intrinsic evaluates to the same value as a constant that we know. If we don't take the undefinedness into account we get a value that doesn't match the actual implementation, and miscompiled code. This was uncovered by Chandler's simplifycfg changes. llvm-svn: 173356
* ConstantFolding: Tweak r173289, it should evaluate in the intptr type, not ↵Benjamin Kramer2013-01-231-18/+15
| | | | | | the index type. llvm-svn: 173293
* ConstantFolding: Evaluate GEP indices in the index type.Benjamin Kramer2013-01-231-2/+11
| | | | | | | This fixes some edge cases that we would get wrong with uint64_ts. PR14986. llvm-svn: 173289
* Make APFloat constructor require explicit semantics.Tim Northover2013-01-221-1/+1
| | | | | | | | | Previously we tried to infer it from the bit width size, with an added IsIEEE argument for the PPC/IEEE 128-bit case, which had a default value. This default value allowed bugs to creep in, where it was inappropriate. llvm-svn: 173138
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-8/+8
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
* Rename VMCore directory to IR.Chandler Carruth2013-01-021-7/+7
| | | | | | | | | | | | | | | | | | Aside from moving the actual files, this patch only updates the build system and the source file comments under lib/... that are relevant. I'll be updating other docs and other files in smaller subsequnet commits. While I've tried to test this, but it is entirely possible that there will still be some build system fallout. Also, note that I've not changed the library name itself: libLLVMCore.a is still the library name. I'd be interested in others' opinions about whether we should rename this as well (I think we should, just not sure what it might break) llvm-svn: 171359
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-6/+6
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* llvm/ConstantFolding.cpp: Make ReadDataFromGlobal() and ↵NAKAMURA Takumi2012-11-081-9/+19
| | | | | | FoldReinterpretLoadFromConstPtr() Big-endian-aware. llvm-svn: 167595
* ConstantFolding.cpp: Whitespace.NAKAMURA Takumi2012-11-051-100/+100
| | | | llvm-svn: 167377
* Revert the majority of the next patch in the address space series:Chandler Carruth2012-11-011-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r165941: Resubmit the changes to llvm core to update the functions to support different pointer sizes on a per address space basis. Despite this commit log, this change primarily changed stuff outside of VMCore, and those changes do not carry any tests for correctness (or even plausibility), and we have consistently found questionable or flat out incorrect cases in these changes. Most of them are probably correct, but we need to devise a system that makes it more clear when we have handled the address space concerns correctly, and ideally each pass that gets updated would receive an accompanying test case that exercises that pass specificaly w.r.t. alternate address spaces. However, from this commit, I have retained the new C API entry points. Those were an orthogonal change that probably should have been split apart, but they seem entirely good. In several places the changes were very obvious cleanups with no actual multiple address space code added; these I have not reverted when I spotted them. In a few other places there were merge conflicts due to a cleaner solution being implemented later, often not using address spaces at all. In those cases, I've preserved the new code which isn't address space dependent. This is part of my ongoing effort to clean out the partial address space code which carries high risk and low test coverage, and not likely to be finished before the 3.2 release looms closer. Duncan and I would both like to see the above issues addressed before we return to these changes. llvm-svn: 167222
* Revert the series of commits starting with r166578 which introduced theChandler Carruth2012-11-011-124/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | getIntPtrType support for multiple address spaces via a pointer type, and also introduced a crasher bug in the constant folder reported in PR14233. These commits also contained several problems that should really be addressed before they are re-committed. I have avoided reverting various cleanups to the DataLayout APIs that are reasonable to have moving forward in order to reduce the amount of churn, and minimize the number of commits that were reverted. I've also manually updated merge conflicts and manually arranged for the getIntPtrType function to stay in DataLayout and to be defined in a plausible way after this revert. Thanks to Duncan for working through this exact strategy with me, and Nick Lewycky for tracking down the really annoying crasher this triggered. (Test case to follow in its own commit.) After discussing with Duncan extensively, and based on a note from Micah, I'm going to continue to back out some more of the more problematic patches in this series in order to ensure we go into the LLVM 3.2 branch with a reasonable story here. I'll send a note to llvmdev explaining what's going on and why. Summary of reverted revisions: r166634: Fix a compiler warning with an unused variable. r166607: Add some cleanup to the DataLayout changes requested by Chandler. r166596: Revert "Back out r166591, not sure why this made it through since I cancelled the command. Bleh, sorry about this! r166591: Delete a directory that wasn't supposed to be checked in yet. r166578: Add in support for getIntPtrType to get the pointer type based on the address space. llvm-svn: 167221
OpenPOWER on IntegriCloud