summaryrefslogtreecommitdiff
path: root/lib/Analysis/ConstantFolding.cpp
Commit message (Collapse)AuthorAge
* Remove old fenv.h workaround for a historic clang driver bugAlp Toker2014-06-09
| | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210485 91177308-0d34-0410-b5e6-96231b3b80d8
* Fold FEnv.h into the implementationAlp Toker2014-06-09
| | | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210483 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a Constant version of stripPointerCasts.Rafael Espindola2014-06-04
| | | | | | Thanks to rnk for the suggestion. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210205 91177308-0d34-0410-b5e6-96231b3b80d8
* Teach the constant folder to look through bitcast constant expressionsChandler Carruth2014-05-15
| | | | | | | | | | | | | | | | | | | | | | | | | | 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/ git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208856 91177308-0d34-0410-b5e6-96231b3b80d8
* Rename ComputeMaskedBits to computeKnownBits. "Masked" has beenJay Foad2014-05-14
| | | | | | inappropriate since it lost its Mask parameter in r154011. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208811 91177308-0d34-0410-b5e6-96231b3b80d8
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-15
| | | | | | instead of comparing to nullptr. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206243 91177308-0d34-0410-b5e6-96231b3b80d8
* Allow constant folding of ceil function whenever feasibleKarthik Bhat2014-03-24
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204583 91177308-0d34-0410-b5e6-96231b3b80d8
* Allow constant folding of round function whenever feasibleKarthik Bhat2014-03-07
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203198 91177308-0d34-0410-b5e6-96231b3b80d8
* Allow constant folding of copysignKarthik Bhat2014-03-06
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203076 91177308-0d34-0410-b5e6-96231b3b80d8
* ConstantFolding: Also fold the vector overloads of our math intrinsics.Benjamin Kramer2014-03-05
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202997 91177308-0d34-0410-b5e6-96231b3b80d8
* Allow constant folding of fma and fmuladdMatt Arsenault2014-03-05
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202914 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix duplicate code in ConstantFoldingMatt Arsenault2014-03-05
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202913 91177308-0d34-0410-b5e6-96231b3b80d8
* [Modules] Move GetElementPtrTypeIterator into the IR library. As itsChandler Carruth2014-03-04
| | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202815 91177308-0d34-0410-b5e6-96231b3b80d8
* Add addrspacecast instruction.Matt Arsenault2013-11-15
| | | | | | Patch by Michele Scandale! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194760 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix another constant folding address space place I missed.Matt Arsenault2013-11-04
| | | | | | This fixes an assertion failure with a different sized address space. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194014 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix a constant folding address space place I missed.Matt Arsenault2013-09-17
| | | | | | | | If address space 0 was smaller than the address space in a constant inttoptr/ptrtoint pair, the wrong mask size would be used. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190899 91177308-0d34-0410-b5e6-96231b3b80d8
* Move variable under condition where it is usedMatt Arsenault2013-09-12
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190567 91177308-0d34-0410-b5e6-96231b3b80d8
* Teach ConstantFolding about pointer address spacesMatt Arsenault2013-08-20
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188831 91177308-0d34-0410-b5e6-96231b3b80d8
* Slightly simplify code with helper functionsMatt Arsenault2013-08-12
| | | | | | | e.g. Use Ty->getPointerElementType() instead of cast<PointerType>(Ty)->getElementType() git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188223 91177308-0d34-0410-b5e6-96231b3b80d8
* Add some braces, and spaces around operatorsMatt Arsenault2013-08-12
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188219 91177308-0d34-0410-b5e6-96231b3b80d8
* ConstantFolding: ComputeMaskedBits wants the scalar size for vectors.Benjamin Kramer2013-04-19
| | | | | | Fixes PR15791. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179859 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix a scalability issue with complex ConstantExprs.Benjamin Kramer2013-04-13
| | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179458 91177308-0d34-0410-b5e6-96231b3b80d8
* Constant fold vector bitcasts of halves similarly to how floats and doubles ↵Michael Ilseman2013-02-26
| | | | | | are folded. Test case included. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176131 91177308-0d34-0410-b5e6-96231b3b80d8
* Formatting.Chad Rosier2013-02-20
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175692 91177308-0d34-0410-b5e6-96231b3b80d8
* Teach the DataLayout aware constant folder to be much more aggressive towardsNick Lewycky2013-02-14
| | | | | | | 'and' instructions. This is a pattern that shows up a lot in ubsan binaries. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175128 91177308-0d34-0410-b5e6-96231b3b80d8
* Conditionalize constant folding of math intrinsics on the availability of an ↵Owen Anderson2013-02-07
| | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174561 91177308-0d34-0410-b5e6-96231b3b80d8
* Signficantly generalize our ability to constant fold floating point ↵Owen Anderson2013-02-06
| | | | | | intrinsics, including ones on half types. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174555 91177308-0d34-0410-b5e6-96231b3b80d8
* ConstantFolding: Fix a crash when encoutering a truncating inttoptr.Benjamin Kramer2013-02-05
| | | | | | This was introduced in r173293. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174424 91177308-0d34-0410-b5e6-96231b3b80d8
* use GEP::accumulateConstantOffset() to replace custom written code to ↵Nuno Lopes2013-02-03
| | | | | | compute GEP offset git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174279 91177308-0d34-0410-b5e6-96231b3b80d8
* ConstantFolding: Add a missing folding that leads to a miscompile.Benjamin Kramer2013-01-24
| | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173356 91177308-0d34-0410-b5e6-96231b3b80d8
* ConstantFolding: Tweak r173289, it should evaluate in the intptr type, not ↵Benjamin Kramer2013-01-23
| | | | | | the index type. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173293 91177308-0d34-0410-b5e6-96231b3b80d8
* ConstantFolding: Evaluate GEP indices in the index type.Benjamin Kramer2013-01-23
| | | | | | | This fixes some edge cases that we would get wrong with uint64_ts. PR14986. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173289 91177308-0d34-0410-b5e6-96231b3b80d8
* Make APFloat constructor require explicit semantics.Tim Northover2013-01-22
| | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173138 91177308-0d34-0410-b5e6-96231b3b80d8
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-02
| | | | | | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
* Rename VMCore directory to IR.Chandler Carruth2013-01-02
| | | | | | | | | | | | | | | | | | 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) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171359 91177308-0d34-0410-b5e6-96231b3b80d8
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-03
| | | | | | | | | | | | | | | | | 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. =] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169131 91177308-0d34-0410-b5e6-96231b3b80d8
* llvm/ConstantFolding.cpp: Make ReadDataFromGlobal() and ↵NAKAMURA Takumi2012-11-08
| | | | | | FoldReinterpretLoadFromConstPtr() Big-endian-aware. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167595 91177308-0d34-0410-b5e6-96231b3b80d8
* ConstantFolding.cpp: Whitespace.NAKAMURA Takumi2012-11-05
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167377 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert the majority of the next patch in the address space series:Chandler Carruth2012-11-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167222 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert the series of commits starting with r166578 which introduced theChandler Carruth2012-11-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167221 91177308-0d34-0410-b5e6-96231b3b80d8
* Add some cleanup to the DataLayout changes requested by Chandler.Micah Villmow2012-10-24
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166607 91177308-0d34-0410-b5e6-96231b3b80d8
* Add in support for getIntPtrType to get the pointer type based on the ↵Micah Villmow2012-10-24
| | | | | | | | | | address space. This checkin also adds in some tests that utilize these paths and updates some of the clients. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166578 91177308-0d34-0410-b5e6-96231b3b80d8
* Resubmit the changes to llvm core to update the functions to support ↵Micah Villmow2012-10-15
| | | | | | different pointer sizes on a per address space basis. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165941 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert 165732 for further review.Micah Villmow2012-10-11
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165747 91177308-0d34-0410-b5e6-96231b3b80d8
* Add in the first iteration of support for llvm/clang/lldb to allow variable ↵Micah Villmow2012-10-11
| | | | | | per address space pointer sizes to be optimized correctly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165726 91177308-0d34-0410-b5e6-96231b3b80d8
* Move TargetData to DataLayout.Micah Villmow2012-10-08
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165402 91177308-0d34-0410-b5e6-96231b3b80d8
* Dont cast away const needlessly. Found by gcc48 -Wcast-qual.Roman Divacky2012-09-06
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163324 91177308-0d34-0410-b5e6-96231b3b80d8
* When constant folding GEP expressions, keep the address space information of ↵Nadav Rotem2012-07-30
| | | | | | | | | | pointers. Together with Ran Chachick <ran.chachick@intel.com> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160954 91177308-0d34-0410-b5e6-96231b3b80d8
* When folding a load from a global constant, if the load started in the middleDuncan Sands2012-07-25
| | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160711 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply r155682, making constant folding more consistent, with a fix to workDan Gohman2012-04-27
| | | | | | | properly with how the code handles all-undef PHI nodes. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155721 91177308-0d34-0410-b5e6-96231b3b80d8