aboutsummaryrefslogtreecommitdiff
path: root/mlir/lib/Bytecode/Reader/BytecodeReader.cpp
diff options
context:
space:
mode:
authorBjorn Pettersson <bjorn.a.pettersson@ericsson.com>2024-07-15 00:09:49 +0200
committerBjorn Pettersson <bjorn.a.pettersson@ericsson.com>2024-07-18 11:25:42 +0200
commit783e07f3a4f4684613ffb4a442c97f25c83f309b (patch)
tree6259f37fa2b26930eb5472ecd5bbfcad9f9e626e /mlir/lib/Bytecode/Reader/BytecodeReader.cpp
parentc661422db04d86b83c1bfeed18e31745a3725357 (diff)
downloadllvm-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