|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
| #
2e912669 |
| 18-Jul-2022 |
Nikita Popov <[email protected]> |
[ConstantRangeTest] Migrate known bits test to generic infrastructure (NFC)
This can't make use of TestBinaryOpExhaustive, but it can make use of the general TestRange approach that collects the pre
[ConstantRangeTest] Migrate known bits test to generic infrastructure (NFC)
This can't make use of TestBinaryOpExhaustive, but it can make use of the general TestRange approach that collects the precise elements in a bit vector.
This allows us to remove the obsolete "op range gatherer" infrastructure.
show more ...
|
| #
b57d6138 |
| 18-Jul-2022 |
Nikita Popov <[email protected]> |
[ConstantRangeTest] Move nowrap binop tests to generic infrastructure (NFC)
Move testing for add/sub with nowrap flags to TestBinaryOpExhaustive, rather than separate homegrown exhaustive testing fu
[ConstantRangeTest] Move nowrap binop tests to generic infrastructure (NFC)
Move testing for add/sub with nowrap flags to TestBinaryOpExhaustive, rather than separate homegrown exhaustive testing functions.
show more ...
|
| #
ba1e04b9 |
| 01-Jul-2022 |
Nikita Popov <[email protected]> |
[ConstantRange] Fix sdiv() with one bit values (PR56333)
Signed one bit values can only be -1 or 0, not positive. The code was interpreting the 1 as -1 and intersecting with a full range rather than
[ConstantRange] Fix sdiv() with one bit values (PR56333)
Signed one bit values can only be -1 or 0, not positive. The code was interpreting the 1 as -1 and intersecting with a full range rather than an empty one.
Fixes https://github.com/llvm/llvm-project/issues/56333.
show more ...
|
| #
d152e50c |
| 25-Jun-2022 |
Kazu Hirata <[email protected]> |
[llvm] Don't use Optional::{hasValue,getValue} (NFC)
|
|
Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4 |
|
| #
9398caf3 |
| 20-May-2022 |
Alexander Shaposhnikov <[email protected]> |
Recommit "[ConstantRange] Improve the implementation of binaryOr"
This recommits https://reviews.llvm.org/rG6990e7477d24ff585ae86549f5280f0be65422a6 as the problematic test has been updated updated
Recommit "[ConstantRange] Improve the implementation of binaryOr"
This recommits https://reviews.llvm.org/rG6990e7477d24ff585ae86549f5280f0be65422a6 as the problematic test has been updated updated in https://reviews.llvm.org/rG3bd112c720dc614a59e3f34ebf9b45075037bfa0.
show more ...
|
| #
54e3bf5f |
| 20-May-2022 |
Douglas Yung <[email protected]> |
Revert "[ConstantRange] Improve the implementation of binaryOr"
This reverts commit 6990e7477d24ff585ae86549f5280f0be65422a6.
This change was causing the test compiler-rt/test/fuzzer/merge_two_step
Revert "[ConstantRange] Improve the implementation of binaryOr"
This reverts commit 6990e7477d24ff585ae86549f5280f0be65422a6.
This change was causing the test compiler-rt/test/fuzzer/merge_two_step.test to fail on our internal bot as well as other build bots such as https://lab.llvm.org/buildbot/#/builders/179/builds/3712.
show more ...
|
| #
6990e747 |
| 19-May-2022 |
Alexander Shaposhnikov <[email protected]> |
[ConstantRange] Improve the implementation of binaryOr
This diff adjusts binaryOr to take advantage of the analysis based on KnownBits.
Differential revision: https://reviews.llvm.org/D125933
Test
[ConstantRange] Improve the implementation of binaryOr
This diff adjusts binaryOr to take advantage of the analysis based on KnownBits.
Differential revision: https://reviews.llvm.org/D125933
Test plan: 1/ ninja check-llvm 2/ ninja check-llvm-unit
show more ...
|
| #
0f4d9f9b |
| 17-May-2022 |
Alexander Shaposhnikov <[email protected]> |
[ConstantRange] Improve the implementation of binaryAnd
This diff adjusts binaryAnd to take advantage of the analysis based on KnownBits.
Differential revision: https://reviews.llvm.org/D125603
Te
[ConstantRange] Improve the implementation of binaryAnd
This diff adjusts binaryAnd to take advantage of the analysis based on KnownBits.
Differential revision: https://reviews.llvm.org/D125603
Test plan: 1/ ninja check-llvm 2/ ninja check-llvm-unit
show more ...
|
| #
2db4dc7e |
| 17-May-2022 |
Nikita Popov <[email protected]> |
[ConstantRange] Implement binaryXor() using known bits
This allows us to compute known high bits. It's not optimal, but better than nothing.
|
| #
a694546f |
| 16-May-2022 |
Nikita Popov <[email protected]> |
[KnownBits] Add operator==
Checking whether two KnownBits are the same is somewhat common, mainly in test code.
I don't think there is a lot of room for confusion with "determine what the KnownBits
[KnownBits] Add operator==
Checking whether two KnownBits are the same is somewhat common, mainly in test code.
I don't think there is a lot of room for confusion with "determine what the KnownBits for an icmp eq would be", as that has a different result type (this is what the eq() method implements, which returns Optional<bool>).
Differential Revision: https://reviews.llvm.org/D125692
show more ...
|
| #
8ab819ad |
| 16-May-2022 |
Nikita Popov <[email protected]> |
[ConstantRange] Add toKnownBits() method
Add toKnownBits() method to mirror fromKnownBits(). We know the top bits that are constant between min and max.
The return value for an empty range is chose
[ConstantRange] Add toKnownBits() method
Add toKnownBits() method to mirror fromKnownBits(). We know the top bits that are constant between min and max.
The return value for an empty range is chosen to be conservative.
show more ...
|
|
Revision tags: llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
| #
1c5d636a |
| 12-Nov-2021 |
Nikita Popov <[email protected]> |
[ConstantRangeTest] Add helper to enumerate APInts (NFC)
While ForeachNumInConstantRange(ConstantRange::getFull(Bits)) works, it's somewhat roundabout, and I keep looking for this function.
|
| #
2060895c |
| 07-Nov-2021 |
Nikita Popov <[email protected]> |
[ConstantRange] Add exact union/intersect (NFC)
For some optimizations on comparisons it's necessary that the union/intersect is exact and not a superset. Add methods that return Optional<ConstantRa
[ConstantRange] Add exact union/intersect (NFC)
For some optimizations on comparisons it's necessary that the union/intersect is exact and not a superset. Add methods that return Optional<ConstantRange> only if the result is exact.
For the sake of simplicity this is implemented by comparing the subset and superset approximations for now, but it should be possible to do this more directly, as unionWith() and intersectWith() already distinguish the cases where the result is imprecise for the preferred range type functionality.
show more ...
|
| #
cf71a5ea |
| 07-Nov-2021 |
Nikita Popov <[email protected]> |
[ConstantRange] Support zero size in isSizeLargerThan()
From an API perspective, it does not make a lot of sense that 0 is not a valid argument to this function. Add the exact check needed to suppor
[ConstantRange] Support zero size in isSizeLargerThan()
From an API perspective, it does not make a lot of sense that 0 is not a valid argument to this function. Add the exact check needed to support it.
show more ...
|
| #
9f0194be |
| 06-Nov-2021 |
Nikita Popov <[email protected]> |
[ConstantRange] Add getEquivalentICmp() variant with offset (NFCI)
Add a variant of getEquivalentICmp() that produces an optional offset. This allows us to create an equivalent icmp for all ranges.
[ConstantRange] Add getEquivalentICmp() variant with offset (NFCI)
Add a variant of getEquivalentICmp() that produces an optional offset. This allows us to create an equivalent icmp for all ranges.
Use this in the with.overflow folding code, which was doing this adjustment separately -- this clarifies that the fold will indeed always apply.
show more ...
|
| #
3348b841 |
| 04-Nov-2021 |
Jakub Kuderski <[email protected]> |
Make enum iteration with seq safe by default
By default `llvm::seq` would happily iterate over enums, which may be unsafe if the enum values are not continuous. This patch disable enum iteration wit
Make enum iteration with seq safe by default
By default `llvm::seq` would happily iterate over enums, which may be unsafe if the enum values are not continuous. This patch disable enum iteration with `llvm::seq` and `llvm::seq_inclusive` and adds two new functions: `enum_seq` and `enum_seq_inclusive`.
To make sure enum iteration is safe, we require users to declare their enum types as iterable by specializing `enum_iteration_traits<SomeEnum>`. Because it's not always possible to add these traits next to enum definition (e.g., for enums defined in external libraries), we provide an escape hatch to allow iteration on per-callsite basis by passing `force_iteration_on_noniterable_enum`.
The main benefit of this approach is that these global declarations via traits can appear just next to enum definitions, making easy to spot when enums are miss-labeled, e.g., after introducing new enum values, whereas `force_iteration_on_noniterable_enum` should stand out and be easy to grep for.
This emerged from a discussion with gchatelet@ about reusing llvm's `Sequence.h` in lieu of https://github.com/GPUOpen-Drivers/llpc/blob/dev/lgc/interface/lgc/EnumIterator.h.
Reviewed By: dblaikie, gchatelet, aaron.ballman
Differential Revision: https://reviews.llvm.org/D107378
show more ...
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1 |
|
| #
03a4f1f3 |
| 06-Nov-2020 |
Roman Lebedev <[email protected]> |
[ConstantRange] Sign-flipping of signedness-invariant comparisons
For certain combination of LHS and RHS constant ranges, the signedness of the relational comparison predicate is irrelevant.
This i
[ConstantRange] Sign-flipping of signedness-invariant comparisons
For certain combination of LHS and RHS constant ranges, the signedness of the relational comparison predicate is irrelevant.
This implements complete and precise model for all predicates, as confirmed by the brute-force tests. I'm not sure if there are some more cases that we can handle here.
In a follow-up, CVP will make use of this.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D90924
show more ...
|
| #
25043c82 |
| 30-Oct-2021 |
Roman Lebedev <[email protected]> |
[NFCI] Introduce `ICmpInst::compare()` and use it where appropriate
As noted in https://reviews.llvm.org/D90924#inline-1076197 apparently this is a pretty common pattern, let's not repeat it yet aga
[NFCI] Introduce `ICmpInst::compare()` and use it where appropriate
As noted in https://reviews.llvm.org/D90924#inline-1076197 apparently this is a pretty common pattern, let's not repeat it yet again, but have it in a common place.
There may be some more places where it could be used, but these are the most obvious ones.
show more ...
|
| #
274b2439 |
| 16-Oct-2021 |
Nikita Popov <[email protected]> |
[ConstantRange] Add fast signed multiply
The multiply() implementation is very slow -- it performs six multiplications in double the bitwidth, which means that it will typically work on allocated AP
[ConstantRange] Add fast signed multiply
The multiply() implementation is very slow -- it performs six multiplications in double the bitwidth, which means that it will typically work on allocated APInts and bypass fast-path implementations. Add an additional implementation that doesn't try to produce anything better than a full range if overflow is possible. At least for the BasicAA use-case, we really don't care about more precise modeling of overflow behavior. The current use of multiply() is fine while the implementation is limited to a single index, but extending it to the multiple-index case makes the compile-time impact untenable.
show more ...
|
| #
587493b4 |
| 15-Oct-2021 |
Nikita Popov <[email protected]> |
[ConstantRange] Compute precise shl range for single elements
For the common case where the shift amount is constant (a single element range) we can easily compute a precise range (up to unsigned en
[ConstantRange] Compute precise shl range for single elements
For the common case where the shift amount is constant (a single element range) we can easily compute a precise range (up to unsigned envelope), so do that.
show more ...
|
| #
9eb8040a |
| 15-Oct-2021 |
Nikita Popov <[email protected]> |
[ConstantRange] Support checking optimality for subset of inputs (NFC)
We always want to check correctness, but for some operations we can only guarantee optimality for a subset of inputs. Accept an
[ConstantRange] Support checking optimality for subset of inputs (NFC)
We always want to check correctness, but for some operations we can only guarantee optimality for a subset of inputs. Accept an additional predicate that determines whether optimality for a given pair of ranges should be checked.
show more ...
|
| #
82e858d1 |
| 15-Oct-2021 |
Nikita Popov <[email protected]> |
[ConstantRange] Better diagnostic for correctness test failure (NFC)
Print a friendly error message including the inputs, result and not-contained element if an exhaustive correctness test fails, sa
[ConstantRange] Better diagnostic for correctness test failure (NFC)
Print a friendly error message including the inputs, result and not-contained element if an exhaustive correctness test fails, same as we do if the optimality test fails.
show more ...
|
| #
a9bceb2b |
| 30-Sep-2021 |
Jay Foad <[email protected]> |
[APInt] Stop using soft-deprecated constructors and methods in llvm. NFC.
Stop using APInt constructors and methods that were soft-deprecated in D109483. This fixes all the uses I found in llvm, exc
[APInt] Stop using soft-deprecated constructors and methods in llvm. NFC.
Stop using APInt constructors and methods that were soft-deprecated in D109483. This fixes all the uses I found in llvm, except for the APInt unit tests which should still test the deprecated methods.
Differential Revision: https://reviews.llvm.org/D110807
show more ...
|
| #
735f4671 |
| 09-Sep-2021 |
Chris Lattner <[email protected]> |
[APInt] Normalize naming on keep constructors / predicate methods.
This renames the primary methods for creating a zero value to `getZero` instead of `getNullValue` and renames predicates like `isAl
[APInt] Normalize naming on keep constructors / predicate methods.
This renames the primary methods for creating a zero value to `getZero` instead of `getNullValue` and renames predicates like `isAllOnesValue` to simply `isAllOnes`. This achieves two things:
1) This starts standardizing predicates across the LLVM codebase, following (in this case) ConstantInt. The word "Value" doesn't convey anything of merit, and is missing in some of the other things.
2) Calling an integer "null" doesn't make any sense. The original sin here is mine and I've regretted it for years. This moves us to calling it "zero" instead, which is correct!
APInt is widely used and I don't think anyone is keen to take massive source breakage on anything so core, at least not all in one go. As such, this doesn't actually delete any entrypoints, it "soft deprecates" them with a comment.
Included in this patch are changes to a bunch of the codebase, but there are more. We should normalize SelectionDAG and other APIs as well, which would make the API change more mechanical.
Differential Revision: https://reviews.llvm.org/D109483
show more ...
|
| #
d6da02d9 |
| 21-Jul-2021 |
Guillaume Chatelet <[email protected]> |
[llvm] Add enum iteration to Sequence
This patch allows iterating typed enum via the ADT/Sequence utility.
It also changes the original design to better separate concerns: - `StrongInt` only deals
[llvm] Add enum iteration to Sequence
This patch allows iterating typed enum via the ADT/Sequence utility.
It also changes the original design to better separate concerns: - `StrongInt` only deals with safe `intmax_t` operations, - `SafeIntIterator` presents the iterator and reverse iterator interface but only deals with safe `StrongInt` internally. - `iota_range` only deals with `SafeIntIterator` internally.
This design ensures that operations are always valid. In particular, "Out of bounds" assertions fire when: - the `value_type` is not representable as an `intmax_t` - iterator operations make internal computation underflow/overflow - the internal representation cannot be converted back to `value_type`
Differential Revision: https://reviews.llvm.org/D106279
show more ...
|