-
Notifications
You must be signed in to change notification settings - Fork 14.4k
[GISel] Teach computeKnownBitsImpl to handle COPY instructions that change bit width. #118924
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@llvm/pr-subscribers-llvm-globalisel Author: Craig Topper (topperc) ChangesThe selectShiftMask ComplexRenderFn on RISCV calls computeKnownBits. I encountered a case where we looked through a G_PHI and found a COPY that was created from an already selected G_ANYEXT from s32 to s64. s32 and s64 integers on RISC-V end up in the same register class. The input to the COPY was an already selected s32 SELECT instruction. We need an s32 SELECT to be legal to support f32 selects. If it isn't used by FP operations, regbank select will assign to GPR. This patch uses KnownBits::anyextOrTrunc to adjust the width when they mismatch. I haven't reduced a test case yet, but wanted to make sure this is the right fix. Full diff: https://github.com/llvm/llvm-project/pull/118924.diff 1 Files Affected:
diff --git a/llvm/lib/CodeGen/GlobalISel/GISelKnownBits.cpp b/llvm/lib/CodeGen/GlobalISel/GISelKnownBits.cpp
index 30cd3ce3baa502..6c15ed3423d3bd 100644
--- a/llvm/lib/CodeGen/GlobalISel/GISelKnownBits.cpp
+++ b/llvm/lib/CodeGen/GlobalISel/GISelKnownBits.cpp
@@ -253,6 +253,7 @@ void GISelKnownBits::computeKnownBitsImpl(Register R, KnownBits &Known,
// For COPYs we don't do anything, don't increase the depth.
computeKnownBitsImpl(SrcReg, Known2, DemandedElts,
Depth + (Opcode != TargetOpcode::COPY));
+ Known2 = Known2.anyextOrTrunc(BitWidth);
Known = Known.intersectWith(Known2);
// If we reach a point where we don't know anything
// just stop looking through the operands.
|
Easier to judge this with the test but probably |
While investigating this, I realized the we shouldn't be promoting s32 G_PHI to s64 on RV64 or we can't support phis of f32 values. Fixing that made the problem disappear for now. |
…hange bit width. The selectShiftMask ComplexRenderFn on RISCV calls computeKnownBits. I encountered a case where we looked through a G_PHI and found a COPY that was created from an already selected G_ANYEXT from s32 to s64. s32 and s64 integers on RISC-V end up in the same register class.a The input to the COPY was an already selected s32 SELECT instruction. We need an s32 SELECT to be legal to support f32 selects. If it isn't used by FP operations, regbank select will assign to GPR. This patch uses KnownBits::anyextOrTrunc to adjust the width when they mismatch. I haven't reduced a test case yet, but wanted to make sure this is the right fix.
I've added a test now. |
The update script doesn't require this to generate the test, but running the test through lit does.
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/23/builds/5587 Here is the relevant piece of the build log for the reference
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/52/builds/4298 Here is the relevant piece of the build log for the reference
|
The sexti32 ComplexRenderFn on RISCV calls computeNumSignBits which calls computeKnownBits.
I encountered a case where we looked through a G_PHI and found a COPY that was created from an already selected G_TRUNC from s64 to s32. s32 and s64 integers on RISC-V end up in the same register class. s32 G_PHI is legal to allow f32 phis on RV64.
This patch uses KnownBits::anyextOrTrunc to adjust the width when they mismatch.