summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/ConstantRange.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [ConstantRange] Respect destination bitwidth for cast results.Florian Hahn2019-12-271-2/+2
| | | | | | | | | | | We returning a full set, we should use ResultBitWidth. Otherwise we might it assertions when the resulting constant ranges are used later on. Reviewers: nikic, spatel, reames Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D71937
* [NFC][KnownBits] Add getMinValue() / getMaxValue() methodsRoman Lebedev2019-12-031-2/+2
| | | | | | | | | | As it can be seen from accompanying cleanup, it is not unheard of to write `~Known.Zero` meaning "what maximal value can this KnownBits produce". But i think `~Known.Zero` isn't *that* self-explanatory, as compared to a method with a name. Note that not all `~Known.Zero` places were cleaned up, only those where this arguably improves things.
* [NFC] ConstantRange::subWithNoWrap(): fixup commentRoman Lebedev2019-11-081-1/+1
|
* [ConstantRange] Add umul_sat()/smul_sat() methodsRoman Lebedev2019-11-081-0/+35
| | | | | | | | | | | | | | | | | | | | | | | Summary: To be used in `ConstantRange::mulWithNoOverflow()`, may in future be useful for when saturating shift/mul ops are added. These are precise as far as i can tell. I initially though i will need `APInt::[us]mul_sat()` for these, but it turned out much simpler to do what `ConstantRange::multiply()` does - perform multiplication in twice the bitwidth, and then truncate. Though here we want saturating signed truncation. Reviewers: nikic, reames, spatel Reviewed By: nikic Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69994
* [CR] ConstantRange::sshl_sat(): check sigdness of the min/max, not rangesRoman Lebedev2019-11-081-2/+2
| | | | | This was pointed out in review, but forgot to stage this change into the commit itself..
* [ConstantRange] Add `ushl_sat()`/`sshl_sat()` methods.Roman Lebedev2019-11-081-0/+20
| | | | | | | | | | | | | | | | | | Summary: To be used in `ConstantRange::shlWithNoOverflow()`, may in future be useful for when saturating shift/mul ops are added. Unlike `ConstantRange::shl()`, these are precise. Reviewers: nikic, spatel, reames Reviewed By: nikic Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69960
* [ConstantRange][LVI] Use overflow flags from `sub` to constrain the rangeRoman Lebedev2019-11-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This notably improves non-negativity deduction: ``` | statistic | old | new | delta | % change | | correlated-value-propagation.NumAShrs | 209 | 227 | 18 | 8.6124% | | correlated-value-propagation.NumAddNSW | 4972 | 4988 | 16 | 0.3218% | | correlated-value-propagation.NumAddNUW | 7141 | 7148 | 7 | 0.0980% | | correlated-value-propagation.NumAddNW | 12113 | 12136 | 23 | 0.1899% | | correlated-value-propagation.NumAnd | 442 | 445 | 3 | 0.6787% | | correlated-value-propagation.NumNSW | 7160 | 7176 | 16 | 0.2235% | | correlated-value-propagation.NumNUW | 13306 | 13316 | 10 | 0.0752% | | correlated-value-propagation.NumNW | 20466 | 20492 | 26 | 0.1270% | | correlated-value-propagation.NumSDivs | 207 | 212 | 5 | 2.4155% | | correlated-value-propagation.NumSExt | 6279 | 6679 | 400 | 6.3704% | | correlated-value-propagation.NumSRems | 28 | 29 | 1 | 3.5714% | | correlated-value-propagation.NumShlNUW | 2793 | 2796 | 3 | 0.1074% | | correlated-value-propagation.NumShlNW | 3964 | 3967 | 3 | 0.0757% | | correlated-value-propagation.NumUDivs | 353 | 358 | 5 | 1.4164% | | instcount.NumAShrInst | 13763 | 13741 | -22 | -0.1598% | | instcount.NumAddInst | 277349 | 277348 | -1 | -0.0004% | | instcount.NumLShrInst | 27437 | 27463 | 26 | 0.0948% | | instcount.NumOrInst | 102677 | 102678 | 1 | 0.0010% | | instcount.NumSDivInst | 8732 | 8727 | -5 | -0.0573% | | instcount.NumSExtInst | 80872 | 80468 | -404 | -0.4996% | | instcount.NumSRemInst | 1679 | 1678 | -1 | -0.0596% | | instcount.NumTruncInst | 62154 | 62153 | -1 | -0.0016% | | instcount.NumUDivInst | 2526 | 2527 | 1 | 0.0396% | | instcount.NumURemInst | 1589 | 1590 | 1 | 0.0629% | | instcount.NumZExtInst | 69405 | 69809 | 404 | 0.5821% | | instcount.TotalInsts | 7439575 | 7439574 | -1 | 0.0000% | ``` Reviewers: nikic, reames, spatel Reviewed By: nikic Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69942
* [ConstantRange] Add `subWithNoWrap()` methodRoman Lebedev2019-11-071-0/+30
| | | | | | | | | | | | | | | | | | | | | Summary: Much like D67339, adds ConstantRange handling for when we know no-wrap behavior of the `sub`. Unlike addWithNoWrap(), we only get lucky re returning empty set for signed wrap. For unsigned, we must perform overflow check manually. A patch that makes use of this in LVI (CVP) to be posted later. Reviewers: nikic, shchenz, efriedma Reviewed By: nikic Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69918
* [ConstantRange] Cleanup addWithNoWrap() by just piggybacking on ↵Roman Lebedev2019-11-071-32/+8
| | | | | | | | | sadd_sat()/uadd_sat() As discussed in https://reviews.llvm.org/D69918 that happens to work as intended, and returns empty set if there is always an overflow because we get lucky with intersection. Since there's now an explicit test for that, let's prefer cleaner code.
* [LVI][CVP] LazyValueInfoImpl::solveBlockValueBinaryOp(): use no-wrap flags ↵Roman Lebedev2019-10-231-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | from `add` op Summary: This was suggested in https://reviews.llvm.org/D69277#1717210 In this form (this is what was suggested, right?), the results aren't staggering (especially since given LVI cross-block focus) this does catch some things (as per test-suite), but not too much: | statistic | old | new | delta | % change | | correlated-value-propagation.NumAddNSW | 4981 | 4982 | 1 | 0.0201% | | correlated-value-propagation.NumAddNW | 12125 | 12126 | 1 | 0.0082% | | correlated-value-propagation.NumCmps | 1199 | 1202 | 3 | 0.2502% | | correlated-value-propagation.NumDeadCases | 112 | 111 | -1 | -0.8929% | | correlated-value-propagation.NumMulNSW | 275 | 278 | 3 | 1.0909% | | correlated-value-propagation.NumMulNUW | 1323 | 1326 | 3 | 0.2268% | | correlated-value-propagation.NumMulNW | 1598 | 1604 | 6 | 0.3755% | | correlated-value-propagation.NumNSW | 7158 | 7167 | 9 | 0.1257% | | correlated-value-propagation.NumNUW | 13304 | 13310 | 6 | 0.0451% | | correlated-value-propagation.NumNW | 20462 | 20477 | 15 | 0.0733% | | correlated-value-propagation.NumOverflows | 4 | 7 | 3 | 75.0000% | | correlated-value-propagation.NumPhis | 15366 | 15381 | 15 | 0.0976% | | correlated-value-propagation.NumSExt | 6273 | 6277 | 4 | 0.0638% | | correlated-value-propagation.NumShlNSW | 1172 | 1171 | -1 | -0.0853% | | correlated-value-propagation.NumShlNUW | 2793 | 2794 | 1 | 0.0358% | | correlated-value-propagation.NumSubNSW | 730 | 736 | 6 | 0.8219% | | correlated-value-propagation.NumSubNUW | 2044 | 2046 | 2 | 0.0978% | | correlated-value-propagation.NumSubNW | 2774 | 2782 | 8 | 0.2884% | | instcount.NumAddInst | 277586 | 277569 | -17 | -0.0061% | | instcount.NumAndInst | 66056 | 66054 | -2 | -0.0030% | | instcount.NumBrInst | 709147 | 709146 | -1 | -0.0001% | | instcount.NumCallInst | 528579 | 528576 | -3 | -0.0006% | | instcount.NumExtractValueInst | 18307 | 18301 | -6 | -0.0328% | | instcount.NumOrInst | 102660 | 102665 | 5 | 0.0049% | | instcount.NumPHIInst | 318008 | 318007 | -1 | -0.0003% | | instcount.NumSelectInst | 46373 | 46370 | -3 | -0.0065% | | instcount.NumSExtInst | 79496 | 79488 | -8 | -0.0101% | | instcount.NumShlInst | 40654 | 40657 | 3 | 0.0074% | | instcount.NumTruncInst | 62251 | 62249 | -2 | -0.0032% | | instcount.NumZExtInst | 68211 | 68221 | 10 | 0.0147% | | instcount.TotalBlocks | 843910 | 843909 | -1 | -0.0001% | | instcount.TotalInsts | 7387448 | 7387423 | -25 | -0.0003% | Reviewers: nikic, reames Reviewed By: nikic Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69321
* [ConstantRange] makeGuaranteedNoWrapRegion(): `shl` supportRoman Lebedev2019-10-201-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If all the shifts amount are already poison-producing, then we can add more poison-producing flags ontop: https://rise4fun.com/Alive/Ocwi Otherwise, we should only consider the possible range of shift amts that don't result in poison. For unsigned range not not overflow, we must not shift out any set bits, and the actual limit for `x` can be computed by backtransforming the maximal value we could ever get out of the `shl` - `-1` through `lshr`. If the `x` is any larger than that then it will overflow. Likewise for signed range, but just in signed domain.. This is based on the general idea outlined by @nikic in https://reviews.llvm.org/D68672#1714990 Reviewers: nikic, sanjoy Reviewed By: nikic Subscribers: hiraditya, llvm-commits, nikic Tags: #llvm Differential Revision: https://reviews.llvm.org/D69217 llvm-svn: 375370
* [ConstantRange] [NFC] replace addWithNoSignedWrap with addWithNoWrap.Chen Zheng2019-10-081-10/+0
| | | | llvm-svn: 374016
* [ConstantRange] add helper function addWithNoWrap().Chen Zheng2019-09-301-0/+51
| | | | | | Differential Revision: https://reviews.llvm.org/D67339 llvm-svn: 373205
* [ConstantRange] Add sdiv() supportNikita Popov2019-06-031-0/+87
| | | | | | | | | | | | | | | | | | | | | | | | | The implementation is conceptually simple: We separate the LHS and RHS into positive and negative components and then also compute the positive and negative components of the result, taking into account that e.g. only pos/pos and neg/neg will give a positive result. However, there's one significant complication: SignedMin / -1 is UB for sdiv, and we can't just ignore it, because the APInt result of SignedMin would break the sign segregation. Instead we drop SignedMin or -1 from the corresponding ranges, taking into account some edge cases with wrapped ranges. Because of the sign segregation, the implementation ends up being nearly fully precise even for wrapped ranges (the remaining imprecision is due to ranges that are both signed and unsigned wrapping and are divided by a trivial divisor like 1). This means that the testing cannot just check the signed envelope as we usually do. Instead we collect all possible results in a bitvector and construct a better sign wrapped range (than the full envelope). Differential Revision: https://reviews.llvm.org/D61238 llvm-svn: 362430
* [ValueTracking][ConstantRange] Distinguish low/high always overflowNikita Popov2019-05-281-9/+9
| | | | | | | | | | | | In order to fold an always overflowing signed saturating add/sub, we need to know in which direction the always overflow occurs. This patch splits up AlwaysOverflows into AlwaysOverflowsLow and AlwaysOverflowsHigh to pass through this information (but it is not used yet). Differential Revision: https://reviews.llvm.org/D62463 llvm-svn: 361858
* [CVP] Remove unnecessary checks for empty GNWR; NFCNikita Popov2019-05-251-2/+1
| | | | | | | | | | The guaranteed no-wrap region is never empty, it always contains at least zero, so these optimizations don't ever apply. To make this more obviously true, replace the conversative return in makeGNWR with an assertion. llvm-svn: 361698
* [ConstantRange] Simplify makeGNWR implementation; NFCNikita Popov2019-05-071-103/+67
| | | | | | | | Compute results in more direct ways, avoid subset intersect operations. Extract the core code for computing mul nowrap ranges into separate static functions, so they can be reused. llvm-svn: 360189
* [ConstantRange] Add srem() supportNikita Popov2019-05-061-0/+44
| | | | | | | | | | | | | | | Add support for srem() to ConstantRange so we can use it in LVI. For srem the sign of the result matches the sign of the LHS. For the RHS only the absolute value is important. Apart from that the logic is like urem. Just like for urem this is only an approximate implementation. The tests check a few specific cases and run an exhaustive test for conservative correctness (but not exactness). Differential Revision: https://reviews.llvm.org/D61207 llvm-svn: 360055
* [ConstantRange] Add makeExactNoWrapRegion()Nikita Popov2019-04-281-4/+10
| | | | | | | | | | | | | | | | | | | | | | | I got confused on the terminology, and the change in D60598 was not correct. I was thinking of "exact" in terms of the result being non-approximate. However, the relevant distinction here is whether the result is * Largest range such that: Forall Y in Other: Forall X in Result: X BinOp Y does not wrap. (makeGuaranteedNoWrapRegion) * Smallest range such that: Forall Y in Other: Forall X not in Result: X BinOp Y wraps. (A hypothetical makeAllowedNoWrapRegion) * Both. (makeExactNoWrapRegion) I'm adding a separate makeExactNoWrapRegion method accepting a single APInt (same as makeExactICmpRegion) and using it in the places where the guarantee is relevant. Differential Revision: https://reviews.llvm.org/D60960 llvm-svn: 359402
* [ConstantRange] Add abs() supportNikita Popov2019-04-261-0/+31
| | | | | | | | | | | | | | Add support for abs() to ConstantRange. This will allow to handle SPF_ABS select flavor in LVI and will also come in handy as a primitive for the srem implementation. The implementation is slightly tricky, because a) abs of signed min is signed min and b) sign-wrapped ranges may have an abs() that is smaller than a full range, so we need to explicitly handle them. Differential Revision: https://reviews.llvm.org/D61084 llvm-svn: 359321
* [ConstantRange] [a, b) udiv a full range is [0, umax(b)).Florian Hahn2019-04-251-2/+0
| | | | | | | | | | Reviewers: nikic, spatel, efriedma Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D60536 llvm-svn: 359180
* [ConstantRange] Add urem supportNikita Popov2019-04-231-0/+15
| | | | | | | | | | | | | Add urem support to ConstantRange, so we can handle in in LVI. This is an approximate implementation that tries to capture the most useful conditions: If the LHS is always strictly smaller than the RHS, then the urem is a no-op and the result is the same as the LHS range. Otherwise the lower bound is zero and the upper bound is min(LHSMax, RHSMax - 1). Differential Revision: https://reviews.llvm.org/D60952 llvm-svn: 359019
* Revert "[ConstantRange] Rename make{Guaranteed -> Exact}NoWrapRegion() NFC"Nikita Popov2019-04-221-7/+8
| | | | | | | | | | This reverts commit 7bf4d7c07f2fac862ef34c82ad0fef6513452445. After thinking about this more, this isn't right, the range is not exact in the same sense as makeExactICmpRegion(). This needs a separate function. llvm-svn: 358876
* [ConstantRange] Rename make{Guaranteed -> Exact}NoWrapRegion() NFCNikita Popov2019-04-221-8/+7
| | | | | | | | Following D60632 makeGuaranteedNoWrapRegion() always returns an exact nowrap region. Rename the function accordingly. This is in line with the naming of makeExactICmpRegion(). llvm-svn: 358875
* [ConstantRange] Add saturating add/sub methodsNikita Popov2019-04-211-0/+36
| | | | | | | | | | | | | | | | Add support for uadd_sat and friends to ConstantRange, so we can handle uadd.sat and friends in LVI. The implementation is forwarding to the corresponding APInt methods with appropriate bounds. One thing worth pointing out here is that the handling of wrapping ranges is not maximally accurate. A simple example is that adding 0 to a wrapped range will return a full range, rather than the original wrapped range. The tests also only check that the non-wrapping envelope is correct and minimal. Differential Revision: https://reviews.llvm.org/D60946 llvm-svn: 358855
* [ConstantRange] Add getNonEmpty() constructorNikita Popov2019-04-211-57/+17
| | | | | | | | | | | | | | ConstantRanges have an annoying special case: If upper and lower are the same, it can be either an empty or a full set. When constructing constant ranges nearly always a full set is intended, but this still requires an explicit check in many places. This revision adds a getNonEmpty() constructor that disambiguates this case: If upper and lower are the same, a full set is created. Differential Revision: https://reviews.llvm.org/D60947 llvm-svn: 358854
* [ConstantRange] Delete unused getSetSizeFangrui Song2019-04-141-8/+0
| | | | | | getSetSize returns an APInt that is 1 bit wider. The APInt is typically 65-bit and requires memory allocation. isSizeStrictlySmallerThan and isSizeLargerThan are preferred. The last use of this helper method was removed by rL302385. llvm-svn: 358347
* [ConstantRange] Disallow NUW | NSW in makeGuaranteedNoWrapRegion()Nikita Popov2019-04-131-18/+14
| | | | | | | | | | | | | | | As motivated in D60598, this drops support for specifying both NUW and NSW in makeGuaranteedNoWrapRegion(). None of the users of this function currently make use of this. When both NUW and NSW are specified, the exact nowrap region has two disjoint parts and makeGNWR() returns one of them. This result doesn't seem to be useful for anything, but makes the semantics of the function fuzzier. Differential Revision: https://reviews.llvm.org/D60632 llvm-svn: 358340
* [ConstantRange] Clarify makeGuaranteedNoWrapRegion() guarantees; NFCNikita Popov2019-04-121-2/+1
| | | | | | | | | | | | | | | | | | | | | makeGuaranteedNoWrapRegion() is actually makeExactNoWrapRegion() as long as only one of NUW or NSW is specified. This is not obvious from the current documentation, and some code seems to think that it is only exact for single-element ranges. Clarify docs and add tests to be more confident this really holds. There are currently no users of makeGuaranteedNoWrapRegion() that pass both NUW and NSW. I think it would be best to drop support for this entirely and then rename the function to makeExactNoWrapRegion(). Knowing that the no-wrap region is exact is useful, because we can backwards-constrain values. What I have in mind in particular is that LVI should be able to constrain values on edges where the with.overflow overflow flag is false. Differential Revision: https://reviews.llvm.org/D60598 llvm-svn: 358305
* [ConstantRange] Add unsignedMulMayOverflow()Nikita Popov2019-04-111-0/+20
| | | | | | | | | | Same as the other ConstantRange overflow checking methods, but for unsigned mul. In this case there is no cheap overflow criterion, so using umul_ov for the implementation. Differential Revision: https://reviews.llvm.org/D60574 llvm-svn: 358228
* [ConstantRange] Delete redundnt {z,s}extOrSelf for multiplicationFangrui Song2019-04-081-7/+0
| | | | | | | These calls are redundant because the quotients have the same BitWidth as MinValue/MaxValue. llvm-svn: 357886
* [ConstantRange] Add signed/unsigned unionWith()Nikita Popov2019-04-071-18/+20
| | | | | | | | | | | | | | | | This extends D59959 to unionWith(), allowing to specify that a non-wrapping unsigned/signed range is preferred. This is somewhat less useful than the intersect case, because union operations are rarer. An example use would the the phi union computed in SCEV. The implementation is mostly a straightforward use of getPreferredRange(), but I also had to adjust some <=/< checks to make sure that no ranges with lower==upper get constructed before they're passed to getPreferredRange(), as these have additional constraints. Differential Revision: https://reviews.llvm.org/D60377 llvm-svn: 357876
* [ConstantRange] Add unsigned and signed intersection typesNikita Popov2019-04-071-13/+65
| | | | | | | | | | | | | | | | | | | | | | | | The intersection of two ConstantRanges may consist of two disjoint ranges. As we can only return one range as the result, we need to return one of the two possible ranges that cover both. Currently the result is picked based on set size. However, this is not always optimal: If we're in an unsigned context, we'd prefer to get a large unsigned range over a small signed range -- the latter effectively becomes a full set in the unsigned domain. This revision adds a PreferredRangeType, which can be either Smallest, Unsigned or Signed. Smallest is the current behavior and Unsigned and Signed are new variants that prefer not to wrap the unsigned/signed domain. The new type isn't used anywhere yet (but SCEV will be a good first user, see D60035). I've also added some comments to illustrate the various cases in intersectWith(), which should hopefully make it more obvious what is going on. Differential Revision: https://reviews.llvm.org/D59959 llvm-svn: 357873
* [ConstantRange] Add isAllNegative() and isAllNonNegative() methodsNikita Popov2019-04-071-0/+15
| | | | | | | | | | | | | Add isAllNegative() and isAllNonNegative() methods to ConstantRange, which determine whether all values in the constant range are negative/non-negative. This is useful for replacing KnownBits isNegative() and isNonNegative() calls when changing code to use constant ranges. Differential Revision: https://reviews.llvm.org/D60264 llvm-svn: 357871
* [ConstantRange] Shl considers full-set shifting to last bit position.Marcello Maggioni2019-04-071-1/+5
| | | | | | | | | | | | | if we do SHL of two 16-bit ranges like [0, 30000) with [1,2) we get "full-set" instead of what I would have expected [0, 60000) which is still in the 16-bit unsigned range. This patch changes the SHL algorithm to allow getting a usable range even in this case. Differential Revision: https://reviews.llvm.org/D57983 llvm-svn: 357854
* [ConstantRange] Add isWrappedSet() and isUpperSignWrapped()Nikita Popov2019-03-271-3/+11
| | | | | | | | | | | | | | | Split off from D59749. This adds isWrappedSet() and isUpperSignWrapped() set with the same behavior as isSignWrappedSet() and isUpperWrapped() for the respectively other domain. The methods isWrappedSet() and isSignWrappedSet() will not consider ranges of the form [X, Max] == [X, 0) and [X, SignedMax] == [X, SignedMin) to be wrapping, while isUpperWrapped() and isUpperSignWrapped() will. Also replace the checks in getUnsignedMin() and friends with method calls that implement the same logic. llvm-svn: 357112
* [ConstantRange] Rename isWrappedSet() to isUpperWrapped()Nikita Popov2019-03-271-16/+16
| | | | | | | | | | | | | | Split out from D59749. The current implementation of isWrappedSet() doesn't do what it says on the tin, and treats ranges like [X, Max] as wrapping, because they are represented as [X, 0) when using half-inclusive ranges. This also makes it inconsistent with the semantics of isSignWrappedSet(). This patch renames isWrappedSet() to isUpperWrapped(), in preparation for the introduction of a new isWrappedSet() method with corrected behavior. llvm-svn: 357107
* [ConstantRange] Exclude full set from isSignWrappedSet()Nikita Popov2019-03-261-2/+1
| | | | | | | | | | | | | | | Split off from D59749. This uses a simpler and more efficient implementation of isSignWrappedSet(), and considers full sets as non-wrapped, to be consistent with isWrappedSet(). Otherwise the behavior is unchanged. There are currently only two users of this function and both already check for isFullSet() || isSignWrappedSet(), so this is not going to cause a change in overall behavior. Differential Revision: https://reviews.llvm.org/D59848 llvm-svn: 357039
* [ConstantRange] Add getFull() + getEmpty() named constructors; NFCNikita Popov2019-03-241-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
* [ConstantRange] Add assertion for KnownBits validity; NFCNikita Popov2019-03-171-0/+2
| | | | | | Following the suggestion in D59475. llvm-svn: 356346
* [ConstantRange] Add fromKnownBits() methodNikita Popov2019-03-171-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
* [ConstantRange] Add overflow check helpersNikita Popov2019-03-151-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
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-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
* [IR] Strip trailing whitespace. NFCBjorn Pettersson2018-07-031-4/+4
| | | | llvm-svn: 336194
* [ConstantRange] Add support of mul in makeGuaranteedNoWrapRegion.Tim Shen2018-06-261-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
* [IR] Use Instruction::isBinaryOp helper instead of raw enum range tests. NFCI.Simon Pilgrim2018-06-221-4/+2
| | | | llvm-svn: 335335
* IWYU for llvm-config.h in llvm, additions.Nico Weber2018-04-301-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
* [ConstantRange] Support for ashr in ConstantRange computationMax Kazantsev2017-12-181-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
* [ConstantRange] Support subtraction in makeGuaranteedNoWrapRegion.Joel Galenson2017-12-051-28/+52
| | | | | | | | Previously ConstantRange::makeGuaranteedNoWrapRegion only handled addition. This adds support for subtraction. Differential Revision: https://reviews.llvm.org/D40036 llvm-svn: 319806
* Reverting r315590; it did not include changes for llvm-tblgen, which is ↵Aaron Ballman2017-10-151-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
OpenPOWER on IntegriCloud