aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/IR/ConstantRange.cpp
AgeCommit message (Collapse)AuthorFilesLines
2019-03-24[ConstantRange] Add getFull() + getEmpty() named constructors; NFCNikita Popov1-64/+64
This adds ConstantRange::getFull(BitWidth) and ConstantRange::getEmpty(BitWidth) named constructors as more readable alternatives to the current ConstantRange(BitWidth, /* full */ false) and similar. Additionally private getFull() and getEmpty() member functions are added which return a full/empty range with the same bit width -- these are commonly needed inside ConstantRange.cpp. The IsFullSet argument in the ConstantRange(BitWidth, IsFullSet) constructor is now mandatory for the few usages that still make use of it. Differential Revision: https://reviews.llvm.org/D59716 llvm-svn: 356852
2019-03-17[ConstantRange] Add assertion for KnownBits validity; NFCNikita Popov1-0/+2
Following the suggestion in D59475. llvm-svn: 356346
2019-03-17[ConstantRange] Add fromKnownBits() methodNikita Popov1-0/+19
Following the suggestion in D59450, I'm moving the code for constructing a ConstantRange from KnownBits out of ValueTracking, which also allows us to test this code independently. I'm adding this method to ConstantRange rather than KnownBits (which would have been a bit nicer API wise) to avoid creating a dependency from Support to IR, where ConstantRange lives. Differential Revision: https://reviews.llvm.org/D59475 llvm-svn: 356339
2019-03-15[ConstantRange] Add overflow check helpersNikita Popov1-0/+92
Add functions to ConstantRange that determine whether the unsigned/signed addition/subtraction of two ConstantRanges may/always/never overflows. This will allow checking overflow conditions based on known constant ranges in addition to known bits. I'm implementing these methods on ConstantRange to allow them to be unit tested independently of any ValueTracking machinery. The tests include exhaustive testing on 4-bit ranges, to make sure the result is both conservatively correct and maximally precise. The OverflowResult enum is redeclared on ConstantRange, because I wanted to avoid a dependency in either direction between ValueTracking.h and ConstantRange.h. Differential Revision: https://reviews.llvm.org/D59193 llvm-svn: 356276
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-07-03[IR] Strip trailing whitespace. NFCBjorn Pettersson1-4/+4
llvm-svn: 336194
2018-06-26[ConstantRange] Add support of mul in makeGuaranteedNoWrapRegion.Tim Shen1-0/+58
Summary: This is trying to add support for r334428. Reviewers: sanjoy Subscribers: jlebar, hiraditya, bixia, llvm-commits Differential Revision: https://reviews.llvm.org/D48399 llvm-svn: 335646
2018-06-22[IR] Use Instruction::isBinaryOp helper instead of raw enum range tests. NFCI.Simon Pilgrim1-4/+2
llvm-svn: 335335
2018-04-30IWYU for llvm-config.h in llvm, additions.Nico Weber1-0/+1
See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
2017-12-18[ConstantRange] Support for ashr in ConstantRange computationMax Kazantsev1-0/+56
Extend the ConstantRange implementation to compute the range of possible values resulting from an arithmetic right shift operation. There will be a follow up patch to leverage this constant range infrastructure in LazyValueInfo. Patch by Surya Kumari Jangala! Differential Revision: https://reviews.llvm.org/D40881 llvm-svn: 320976
2017-12-05[ConstantRange] Support subtraction in makeGuaranteedNoWrapRegion.Joel Galenson1-28/+52
Previously ConstantRange::makeGuaranteedNoWrapRegion only handled addition. This adds support for subtraction. Differential Revision: https://reviews.llvm.org/D40036 llvm-svn: 319806
2017-10-15Reverting r315590; it did not include changes for llvm-tblgen, which is ↵Aaron Ballman1-1/+1
causing link errors for several people. Error LNK2019 unresolved external symbol "public: void __cdecl `anonymous namespace'::MatchableInfo::dump(void)const " (?dump@MatchableInfo@?A0xf4f1c304@@QEBAXXZ) referenced in function "public: void __cdecl `anonymous namespace'::AsmMatcherEmitter::run(class llvm::raw_ostream &)" (?run@AsmMatcherEmitter@?A0xf4f1c304@@QEAAXAEAVraw_ostream@llvm@@@Z) llvm-tblgen D:\llvm\2017\utils\TableGen\AsmMatcherEmitter.obj 1 llvm-svn: 315854
2017-10-12[dump] Remove NDEBUG from test to enable dump methods [NFC]Don Hinton1-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
2017-06-19[IR] Fix some Clang-tidy modernize-use-using warnings; other minor fixes (NFC).Eugene Zelenko1-2/+11
llvm-svn: 305755
2017-06-16[ConstantRange] Implement getSignedMin/Max in a less complicated and faster wayCraig Topper1-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
2017-06-06Sort the remaining #include lines in include/... and lib/....Chandler Carruth1-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
2017-06-05[ConstantRange] Remove costly udivrem from ConstantRange::truncateCraig Topper1-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
2017-05-10[ConstantRange] Fix the early out in ConstantRange::multiply for positive ↵Craig Topper1-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
2017-05-09[ConstantRange] Rewrite shl to avoid repeated calls to getUnsignedMax and ↵Craig Topper1-7/+11
avoid creating the min APInt until we're sure we need it. Use inplace shift operations. llvm-svn: 302510
2017-05-09[ConstantRange] Combine the two adds max+1 in lshr into a single addition.Craig Topper1-4/+4
llvm-svn: 302509
2017-05-09[ConstantRange] Use APInt::isNullValue in place of comparing with 0. The ↵Craig Topper1-4/+4
compiler should be able to generate slightly better code for the former. NFC llvm-svn: 302508
2017-05-07[ConstantRange][SimplifyCFG] Add a helper method to allow SimplifyCFG to ↵Craig Topper1-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
2017-05-07[ConstantRange] Remove 'Of' from name of ↵Craig Topper1-9/+9
ConstantRange::isSizeStrictlySmallerThanOf so that it reads better. NFC llvm-svn: 302383
2017-04-30[ConstantRange] Fix a couple cases where we were possibly throwing away an ↵Craig Topper1-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
2017-04-29[ConstantRange] Use APInt::getOneBitSet to shorten some code. NFCCraig Topper1-5/+2
llvm-svn: 301753
2017-04-29[ConstantRange] Replace getMaxValue+zext with getLowBitsSet. Replace ↵Craig Topper1-3/+2
zero-init+setBit with getOneBitSet. NFC llvm-svn: 301752
2017-04-29[ConstantRange] Use APInt::operator-= to remove temporary APInts.Craig Topper1-4/+4
llvm-svn: 301751
2017-04-29[ConstantRange] Use ternary operator instead of 'if' to avoid copying an ↵Craig Topper1-10/+4
APInt and then possibly copying over it. llvm-svn: 301741
2017-04-29[ConstantRange] Add std::move to a bunch of places that pass local APInts to ↵Craig Topper1-24/+25
ConstantRange constructor. The ConstantRange constructor takes APInt by value so without these moves we are making copies. llvm-svn: 301740
2017-04-29[ConstantRange] Remove a temporary APInt I meant to delete in r300621. NFCCraig Topper1-1/+0
llvm-svn: 301737
2017-04-29[ConstantRange] Improve the efficiency of one of the ConstantRange constructors.Craig Topper1-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
2017-04-28[ConstantRange] Use APInt::isNullValue rather than APInt::isMinValue where ↵Craig Topper1-2/+2
it would make more sense to thing of 0 as 0 rather than the minimum unsigned value. NFC llvm-svn: 301696
2017-04-28[ConstantRange] Use const references to prevent a couple APInt copies. NFCCraig Topper1-2/+2
llvm-svn: 301694
2017-04-18[ConstantRange] Optimize APInt creation in getSignedMax/getSignedMin.Craig Topper1-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
2017-04-18[ConstantRange] fix doxygen comment formatting; NFCSanjay Patel1-76/+0
llvm-svn: 300554
2017-04-13[IR] Remove the APIntMoveTy typedef from ConstantRange. Use APInt type directly.Craig Topper1-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
2017-03-20[ConstantRange] Add setSizeSmallerThanOf method.Michael Zolotukhin1-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
2017-01-28Cleanup dump() functions.Matthias Braun1-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
2016-12-01Factor out common parts of LVI and Float2Int into ConstantRange [NFCI]Philip Reames1-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
2016-10-21Analysis: Move llvm::getConstantRangeFromMetadata to IR library.Peter Collingbourne1-0/+22
We're about to start using it there. Differential Revision: https://reviews.llvm.org/D25877 llvm-svn: 284865
2016-10-19Introduce ConstantRange.addWithNoSignedWrapArtur Pilipenko1-0/+13
To be used by upcoming change to IndVarSimplify Reviewed By: sanjoy Differential Revision: https://reviews.llvm.org/D25732 llvm-svn: 284597
2016-10-02[ConstantRange] Make getEquivalentICmp smarterSanjoy Das1-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
2016-10-02Revert r283057 and r283058Sanjoy Das1-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
2016-10-02[ConstantRange] Make getEquivalentICmp smarterSanjoy Das1-0/+8
This change teaches getEquivalentICmp to be smarter about generating ICMP_NE and ICMP_EQ predicates. llvm-svn: 283057
2016-06-19fix formatting, typo; NFCSanjay Patel1-53/+53
llvm-svn: 273118
2016-06-06Fix spelling and capitalization in comments. NFCNick Lewycky1-2/+2
llvm-svn: 271862
2016-05-27Don't generate unnecessary signed ConstantRange during multiply. NFCPete Cooper1-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
2016-05-19[ConstantRange] Add an getEquivalentICmp helperSanjoy Das1-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
2016-05-04"Reapply r268521 "[InstCombine] Canonicalize icmp instructions based on ↵Balaram Makam1-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
2016-05-04Revert "[InstCombine] Canonicalize icmp instructions based on dominating ↵Balaram Makam1-12/+0
conditions." This reverts commit 573a40f79b35cf3e71db331bb00f6a84f03b835d. llvm-svn: 268530
generated by cgit v1.1 at 2025-10-17 02:57:37 +0000