summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/ConstantFolding.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Add some cleanup to the DataLayout changes requested by Chandler.Micah Villmow2012-10-241-2/+1
| | | | llvm-svn: 166607
* Add in support for getIntPtrType to get the pointer type based on the ↵Micah Villmow2012-10-241-115/+123
| | | | | | | | | address space. This checkin also adds in some tests that utilize these paths and updates some of the clients. llvm-svn: 166578
* Resubmit the changes to llvm core to update the functions to support ↵Micah Villmow2012-10-151-5/+7
| | | | | | different pointer sizes on a per address space basis. llvm-svn: 165941
* Revert 165732 for further review.Micah Villmow2012-10-111-7/+5
| | | | llvm-svn: 165747
* Add in the first iteration of support for llvm/clang/lldb to allow variable ↵Micah Villmow2012-10-111-5/+7
| | | | | | per address space pointer sizes to be optimized correctly. llvm-svn: 165726
* Move TargetData to DataLayout.Micah Villmow2012-10-081-17/+17
| | | | llvm-svn: 165402
* Dont cast away const needlessly. Found by gcc48 -Wcast-qual.Roman Divacky2012-09-061-1/+2
| | | | llvm-svn: 163324
* When constant folding GEP expressions, keep the address space information of ↵Nadav Rotem2012-07-301-3/+19
| | | | | | | | pointers. Together with Ran Chachick <ran.chachick@intel.com> llvm-svn: 160954
* When folding a load from a global constant, if the load started in the middleDuncan Sands2012-07-251-5/+8
| | | | | | | | | | of an array element (rather than at the beginning of the element) and extended into the next element, then the load from the second element was being handled wrong due to incorrect updating of the notion of which byte to load next. This fixes PR13442. Thanks to Chris Smowton for reporting the problem, analyzing it and providing a fix. llvm-svn: 160711
* Reapply r155682, making constant folding more consistent, with a fix to workDan Gohman2012-04-271-7/+20
| | | | | | properly with how the code handles all-undef PHI nodes. llvm-svn: 155721
OpenPOWER on IntegriCloud