summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/ConstantRange.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [dump] Remove NDEBUG from test to enable dump methods [NFC]Don Hinton2017-10-121-1/+1
| | | | | | | | | | | | | | | Summary: Add LLVM_FORCE_ENABLE_DUMP cmake option, and use it along with LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP. Remove NDEBUG and only use LLVM_ENABLE_DUMP to enable dump methods. Move definition of LLVM_ENABLE_DUMP from config.h to llvm-config.h so it'll be picked up by public headers. Differential Revision: https://reviews.llvm.org/D38406 llvm-svn: 315590
* [IR] Fix some Clang-tidy modernize-use-using warnings; other minor fixes (NFC).Eugene Zelenko2017-06-191-2/+11
| | | | llvm-svn: 305755
* [ConstantRange] Implement getSignedMin/Max in a less complicated and faster wayCraig Topper2017-06-161-15/+2
| | | | | | | | | | | | | | Summary: As far as I can tell we should be able to implement these almost the same way we do unsigned, but using signed comparisons and checks for min signed value instead of min unsigned value. Reviewers: pete, davide, sanjoy Reviewed By: davide Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33815 llvm-svn: 305607
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* [ConstantRange] Remove costly udivrem from ConstantRange::truncateCraig Topper2017-06-051-15/+19
| | | | | | | | | | | | Truncate currently uses a udivrem call which is going to be slow particularly for larger than 64-bit widths. As far as I can tell all we were trying to do was modulo LowerDiv by (MaxValue+1) and make sure whatever value was effectively subtracted from LowerDiv was also subtracted from UpperDiv. This patch recognizes that MaxValue+1 is a power of 2 so we can just use a bitwise AND to accomplish a modulo operation or isolate the upper bits. Differential Revision: https://reviews.llvm.org/D32672 llvm-svn: 304733
* [ConstantRange] Fix the early out in ConstantRange::multiply for positive ↵Craig Topper2017-05-101-1/+2
| | | | | | | | | | numbers to really do what the comment says r271020 added an early out to skip the signed multiply portion of ConstantRange::multiply. The comment says we don't need to do signed multiply if the range is only positive numbers, but the implemented check only ensures that the start of the range is positive. It doesn't look at the end of the range. This patch checks the end of the range instead. Because Upper is one more than the end we have to see if its positive or if its one past the last positive number. llvm-svn: 302717
* [ConstantRange] Rewrite shl to avoid repeated calls to getUnsignedMax and ↵Craig Topper2017-05-091-7/+11
| | | | | | avoid creating the min APInt until we're sure we need it. Use inplace shift operations. llvm-svn: 302510
* [ConstantRange] Combine the two adds max+1 in lshr into a single addition.Craig Topper2017-05-091-4/+4
| | | | llvm-svn: 302509
* [ConstantRange] Use APInt::isNullValue in place of comparing with 0. The ↵Craig Topper2017-05-091-4/+4
| | | | | | compiler should be able to generate slightly better code for the former. NFC llvm-svn: 302508
* [ConstantRange][SimplifyCFG] Add a helper method to allow SimplifyCFG to ↵Craig Topper2017-05-071-0/+11
| | | | | | | | | | determine if a ConstantRange has more than 8 elements without requiring an allocation if the ConstantRange is 64-bits wide. Previously SimplifyCFG used getSetSize which returns an APInt that is 1 bit wider than the ConstantRange's bit width. In the reasonably common case that the ConstantRange is 64-bits wide, this requires returning a 65-bit APInt. APInt's can only store 64-bits without a memory allocation so this is inefficient. The new method takes the 8 as an input and tells if the range contains more than that many elements without requiring any wider math. llvm-svn: 302385
* [ConstantRange] Remove 'Of' from name of ↵Craig Topper2017-05-071-9/+9
| | | | | | ConstantRange::isSizeStrictlySmallerThanOf so that it reads better. NFC llvm-svn: 302383
* [ConstantRange] Fix a couple cases where we were possibly throwing away an ↵Craig Topper2017-04-301-2/+2
| | | | | | | | APInt allocation we could reuse. NFC This uses setAllBits to replace getMaxValue and operator=(uint64_t) instead of constructing an APInt from uint64_t. llvm-svn: 301761
* [ConstantRange] Use APInt::getOneBitSet to shorten some code. NFCCraig Topper2017-04-291-5/+2
| | | | llvm-svn: 301753
* [ConstantRange] Replace getMaxValue+zext with getLowBitsSet. Replace ↵Craig Topper2017-04-291-3/+2
| | | | | | zero-init+setBit with getOneBitSet. NFC llvm-svn: 301752
* [ConstantRange] Use APInt::operator-= to remove temporary APInts.Craig Topper2017-04-291-4/+4
| | | | llvm-svn: 301751
* [ConstantRange] Use ternary operator instead of 'if' to avoid copying an ↵Craig Topper2017-04-291-10/+4
| | | | | | APInt and then possibly copying over it. llvm-svn: 301741
* [ConstantRange] Add std::move to a bunch of places that pass local APInts to ↵Craig Topper2017-04-291-24/+25
| | | | | | | | ConstantRange constructor. The ConstantRange constructor takes APInt by value so without these moves we are making copies. llvm-svn: 301740
* [ConstantRange] Remove a temporary APInt I meant to delete in r300621. NFCCraig Topper2017-04-291-1/+0
| | | | llvm-svn: 301737
* [ConstantRange] Improve the efficiency of one of the ConstantRange constructors.Craig Topper2017-04-291-6/+3
| | | | | | | | | | We were default constructing the Lower/Upper APInts. Then creating min or max value, then doing a move assignment to Lower and copy assignment to upper. The copy assignment operator in particular has an out of line function call that has to examine whether or not a previous allocation exists that can be reused which of course it can't in this case. The new code creates the min/max value first, move constructs Lower from it then copy constructs Upper from Lower. This also seems to have convinced a self host build that this constructor can be inlined more readily into other methods in ConstantRange. llvm-svn: 301736
* [ConstantRange] Use APInt::isNullValue rather than APInt::isMinValue where ↵Craig Topper2017-04-281-2/+2
| | | | | | it would make more sense to thing of 0 as 0 rather than the minimum unsigned value. NFC llvm-svn: 301696
* [ConstantRange] Use const references to prevent a couple APInt copies. NFCCraig Topper2017-04-281-2/+2
| | | | llvm-svn: 301694
* [ConstantRange] Optimize APInt creation in getSignedMax/getSignedMin.Craig Topper2017-04-181-8/+8
| | | | | | | | | | We were creating an APInt at the top of these methods that isn't always returned. For ranges wider than 64-bits this results in an allocation and deallocation when its not used. In getSignedMax we were creating Upper-1 to use in a compare and then creating it again for a return value. The compiler is unable to determine that these can be shared. So help it out and create the Upper-1 in a temporary that can be reused. This provides a little compile time improvement. llvm-svn: 300621
* [ConstantRange] fix doxygen comment formatting; NFCSanjay Patel2017-04-181-76/+0
| | | | llvm-svn: 300554
* [IR] Remove the APIntMoveTy typedef from ConstantRange. Use APInt type directly.Craig Topper2017-04-131-2/+2
| | | | | | This typedef used to be conditional based on whether rvalue references were supported. Looks like it got left behind when we switched to always having rvalue references with c++11. I don't think it provides any value now. llvm-svn: 300146
* [ConstantRange] Add setSizeSmallerThanOf method.Michael Zolotukhin2017-03-201-10/+24
| | | | | | | | | | | | | | | | | | | | | | | | Summary: ConstantRange class currently has a method getSetSize, which is mostly used to compare set sizes of two constant ranges (there is only one spot where it's used in a slightly different scenario). This patch introduces setSizeSmallerThanOf method, which does such comparison in a more efficient way. In the original method we have to extend our types to (BitWidth+1), which can result it using slow case of APInt, extra memory allocations, etc. The change is supposed to not change any functionality, but it slightly improves compile time. Here is compile time improvements that I observed on CTMark: * tramp3d-v4 -2.02% * pairlocalalign -1.82% * lencod -1.67% Reviewers: sanjoy, atrick, pete Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31104 llvm-svn: 298236
* Cleanup dump() functions.Matthias Braun2017-01-281-0/+2
| | | | | | | | | | | | | | | | | | We had various variants of defining dump() functions in LLVM. Normalize them (this should just consistently implement the things discussed in http://lists.llvm.org/pipermail/cfe-dev/2014-January/034323.html For reference: - Public headers should just declare the dump() method but not use LLVM_DUMP_METHOD or #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) - The definition of a dump method should look like this: #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) LLVM_DUMP_METHOD void MyClass::dump() { // print stuff to dbgs()... } #endif llvm-svn: 293359
* Factor out common parts of LVI and Float2Int into ConstantRange [NFCI]Philip Reames2016-12-011-0/+79
| | | | | | | | | | This just extracts out the transfer rules for constant ranges into a single shared point. As it happens, neither bit of code actually overlaps in terms of the handled operators, but with this change that could easily be tweaked in the future. I also want to have this separated out to make experimenting with a eager value info implementation and possibly a ValueTracking-like fixed depth recursion peephole version. There's no reason all four of these can't share a common implementation which reduces the chances of bugs. Differential Revision: https://reviews.llvm.org/D27294 llvm-svn: 288413
* Analysis: Move llvm::getConstantRangeFromMetadata to IR library.Peter Collingbourne2016-10-211-0/+22
| | | | | | | | We're about to start using it there. Differential Revision: https://reviews.llvm.org/D25877 llvm-svn: 284865
* Introduce ConstantRange.addWithNoSignedWrapArtur Pilipenko2016-10-191-0/+13
| | | | | | | | | | To be used by upcoming change to IndVarSimplify Reviewed By: sanjoy Differential Revision: https://reviews.llvm.org/D25732 llvm-svn: 284597
* [ConstantRange] Make getEquivalentICmp smarterSanjoy Das2016-10-021-0/+8
| | | | | | | | | | | This change teaches getEquivalentICmp to be smarter about generating ICMP_NE and ICMP_EQ predicates. An earlier version of this change was landed as rL283057 which had a use-after-free bug. This new version has a fix for that bug, and a (C++ unittests/) test case that would have triggered it rL283057. llvm-svn: 283078
* Revert r283057 and r283058Sanjoy Das2016-10-021-8/+0
| | | | | | | | | | | They've broken the sanitizer-bootstrap bots. Reverting while I investigate. Original commit messages: r283057: "[ConstantRange] Make getEquivalentICmp smarter" r283058: "[SCEV] Rely on ConstantRange instead of custom logic; NFCI" llvm-svn: 283062
* [ConstantRange] Make getEquivalentICmp smarterSanjoy Das2016-10-021-0/+8
| | | | | | | This change teaches getEquivalentICmp to be smarter about generating ICMP_NE and ICMP_EQ predicates. llvm-svn: 283057
* fix formatting, typo; NFCSanjay Patel2016-06-191-53/+53
| | | | llvm-svn: 273118
* Fix spelling and capitalization in comments. NFCNick Lewycky2016-06-061-2/+2
| | | | llvm-svn: 271862
* Don't generate unnecessary signed ConstantRange during multiply. NFCPete Cooper2016-05-271-0/+7
| | | | | | | | | | | | | | r231483 taught ConstantRange::multiply to be clever about signed vs unsigned ranges. For example, an unsigned range could be full-set while the signed range is more specific than that. In looking at the allocations trace for LTO'ing verify-uselistorder (see r236629 for details), millions of allocations are from APInt, many of which come from ConstantRange's. This change tries to avoid some (3.2 million) allocations by returning the unsigned range if its suitable. The checks here are that it should not be a wrapping range, and should be positive. That should be enough to check for ranges such as [1, 10) which the signed range will be equal to, if we were to calculate it. Differential Revision: http://reviews.llvm.org/D20723 Reviewed by James Molloy llvm-svn: 271020
* [ConstantRange] Add an getEquivalentICmp helperSanjoy Das2016-05-191-0/+26
| | | | | | | Currently only its unit test uses it, but this will be used in a later change to simplify some logic in the GuardWidening pass. llvm-svn: 270018
* "Reapply r268521 "[InstCombine] Canonicalize icmp instructions based on ↵Balaram Makam2016-05-041-0/+12
| | | | | | | | | dominating conditions."" This reapplies commit r268521, that was reverted in r268530 due to a test failure in select-implied.ll Modified the test case to reflect the new change. llvm-svn: 268557
* Revert "[InstCombine] Canonicalize icmp instructions based on dominating ↵Balaram Makam2016-05-041-12/+0
| | | | | | | | conditions." This reverts commit 573a40f79b35cf3e71db331bb00f6a84f03b835d. llvm-svn: 268530
* [InstCombine] Canonicalize icmp instructions based on dominating conditions.Balaram Makam2016-05-041-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch canonicalizes conditions based on the constant range information of the dominating branch condition. For example: %cmp = icmp slt i64 %a, 0 br i1 %cmp, label %land.lhs.true, label %lor.rhs lor.rhs: %cmp2 = icmp sgt i64 %a, 0 Would now be canonicalized into: %cmp = icmp slt i64 %a, 0 br i1 %cmp, label %land.lhs.true, label %lor.rhs lor.rhs: %cmp2 = icmp ne i64 %a, 0 Reviewers: mcrosier, gberry, t.p.northover, llvm-commits, reames, hfinkel, sanjoy, majnemer Subscribers: MatzeB, majnemer, mcrosier Differential Revision: http://reviews.llvm.org/D18841 llvm-svn: 268521
* [ConstantRange] Generalize makeGuaranteedNoWrapRegion to work on rangesSanjoy Das2016-03-031-12/+20
| | | | | | | This will be used in a later patch to ScalarEvolution. Right now only the unit tests exercise the newly added code. llvm-svn: 262637
* [ConstantRange] Add umin/smin operatorsPhilip Reames2016-02-261-0/+26
| | | | | | | | This was split off from http://reviews.llvm.org/D17184. Reviewed by: Sanjoy llvm-svn: 262080
* [ConstantRange] Rename a method and add more docSanjoy Das2016-02-221-3/+3
| | | | | | | | Rename makeNoWrapRegion to a more obvious makeGuaranteedNoWrapRegion, and add a comment about the counter-intuitive aspects of the function. This is to help prevent cases like PR26628. llvm-svn: 261532
* Annotate dump() methods with LLVM_DUMP_METHOD, addressing Richard Smith ↵Yaron Keren2016-01-291-1/+1
| | | | | | | | r259192 post commit comment. clang part in r259232, this is the LLVM part of the patch. llvm-svn: 259240
* [IR] Add a `makeNoWrapRegion` method to `ConstantRange`Sanjoy Das2015-10-221-0/+53
| | | | | | | | | | | | Summary: This will be used in a future change to ScalarEvolution. Reviewers: hfinkel, reames, nlewycky Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13612 llvm-svn: 250975
* [ConstantRange] Split makeICmpRegion in two.Sanjoy Das2015-03-181-3/+14
| | | | | | | | | | | | | | | | | | | | Summary: This change splits `makeICmpRegion` into `makeAllowedICmpRegion` and `makeSatisfyingICmpRegion` with slightly different contracts. The first one is useful for determining what values some expression //may// take, given that a certain `icmp` evaluates to true. The second one is useful for determining what values are guaranteed to //satisfy// a given `icmp`. Reviewers: nlewycky Reviewed By: nlewycky Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8345 llvm-svn: 232575
* [ConstantRange] Teach multiply to be cleverer about signed ranges.James Molloy2015-03-061-1/+27
| | | | | | | | | | | | | Multiplication is not dependent on signedness, so just treating all input ranges as unsigned is not incorrect. However it will cause overly pessimistic ranges (such as full-set) when used with signed negative values. Teach multiply to try to interpret its inputs as both signed and unsigned, and then to take the most specific (smallest population) as its result. llvm-svn: 231483
* [Modules] Move the ConstantRange class into the IR library. This isChandler Carruth2014-03-041-0/+734
a bit surprising, as the class is almost entirely abstracted away from any particular IR, however it encodes the comparsion predicates which mutate ranges as ICmp predicate codes. This is reasonable as they're used for both instructions and constants. Thus, it belongs in the IR library with instructions and constants. llvm-svn: 202838
OpenPOWER on IntegriCloud