diff options
| author | Bjorn Pettersson <bjorn.a.pettersson@ericsson.com> | 2024-07-15 00:09:49 +0200 |
|---|---|---|
| committer | Bjorn Pettersson <bjorn.a.pettersson@ericsson.com> | 2024-07-18 11:25:42 +0200 |
| commit | 783e07f3a4f4684613ffb4a442c97f25c83f309b (patch) | |
| tree | 6259f37fa2b26930eb5472ecd5bbfcad9f9e626e /mlir/lib/Bytecode/Reader/BytecodeReader.cpp | |
| parent | c661422db04d86b83c1bfeed18e31745a3725357 (diff) | |
| download | llvm-783e07f3a4f4684613ffb4a442c97f25c83f309b.zip llvm-783e07f3a4f4684613ffb4a442c97f25c83f309b.tar.gz llvm-783e07f3a4f4684613ffb4a442c97f25c83f309b.tar.bz2 | |
[InstCombine] Add tests cases related to demanded use bits for ashr
When trying to improve value tracking in
https://github.com/llvm/llvm-project/pull/97693
some regressions was found due to a "weirdness" in simplify demanded
use bits for ashr. Normally an ashr is replaced by lshr when the
shifted in bits aren't demanded. Some years ago (see commit
22178dd33b346020) there was a test case motivating to keep the ashr
when any sign bit (besides the shifted in bits) was demanded. The
weird part about it is that the better we get at analysing known sign
bits, the less likely it is that we canonicalize from ashr to lshr.
That makes it hard to tune other combines to work based on the
canonicalization, as well as possibly resulting in unexpected
regressions when improving value tracking.
This patch adds a test case for which it would be better to
canonicalize ashr into lshr when possible. Worth mentioning is also
that reverting 22178dd33b346020 doesn't seem to cause regressions
in any other lit tests (not even the one added in 22178dd33b346020).
Diffstat (limited to 'mlir/lib/Bytecode/Reader/BytecodeReader.cpp')
0 files changed, 0 insertions, 0 deletions
