[all-commits] [llvm/llvm-project] b8c4c5: [InstCombine] Turn AShr into LShr more often in Si...
Björn Pettersson via All-commits
all-commits at lists.llvm.org
Thu Jul 18 02:46:36 PDT 2024
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: b8c4c58ecf186dd91f40bdff4d1bdad403435789
https://github.com/llvm/llvm-project/commit/b8c4c58ecf186dd91f40bdff4d1bdad403435789
Author: Bjorn Pettersson <bjorn.a.pettersson at ericsson.com>
Date: 2024-07-18 (Thu, 18 Jul 2024)
Changed paths:
M llvm/lib/Transforms/InstCombine/InstCombineSimplifyDemanded.cpp
M llvm/test/Transforms/InstCombine/ashr-demand.ll
Log Message:
-----------
[InstCombine] Turn AShr into LShr more often in SimplifyDemandedUseBits (#99155)
The functional change here is to undo "llvm-svn: 311773", aka D36936,
aka commit 22178dd33b3460207b8. That patch avoided to convert AShr
into LShr in SimplifyDemandedUseBits based on known sign bits
analysis. Even if it would be legal to turn the shift into a
logical shift (given by the fact that the shifted in bits wasn't
demanded), that patch prevented converting the shift into LShr when
any of the original sign bits were demanded.
One side effect of the reverted functionalty was that the better we
were at computing number of sign bits, the less likely it was that
we would replace AShr by LShr during SimplifyDemandedUseBits. This
was seen in https://github.com/llvm/llvm-project/pull/97693/ when
an improvement of ComputeNumSignBits resulted in regressions due
to no longer rewriting AShr to LShr.
The test case from D36936 still passes after this commit. So it seems
like at least the compiler has been taught how to optimize that
scenario even if we do the AShr->LShr transform more aggressively.
To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications
More information about the All-commits
mailing list