[SelectionDAG] Add support for extending masked loads in computeKnownBits #115450
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…Bits We already support computing known bits for extending loads, but not for masked loads. For now I've only added support for zero-extends because that's the only thing currently tested. Even when the passthru value is poison we still know the top X bits are zero.
|
@llvm/pr-subscribers-llvm-selectiondag Author: David Sherwood (david-arm) ChangesWe already support computing known bits for extending loads, but not for masked loads. For now I've only added support for zero-extends because that's the only thing currently tested. Even when the passthru value is poison we still know the top X bits are zero. Full diff: https://github.com/llvm/llvm-project/pull/115450.diff 2 Files Affected:
diff --git a/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp b/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
index 203e14f6cde3e3..901e63c47fac17 100644
--- a/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
+++ b/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
@@ -3920,6 +3920,19 @@ KnownBits SelectionDAG::computeKnownBits(SDValue Op, const APInt &DemandedElts,
Known.Zero.setBitsFrom(1);
break;
}
+ case ISD::MGATHER:
+ case ISD::MLOAD: {
+ ISD::LoadExtType ETy =
+ (Opcode == ISD::MGATHER)
+ ? cast<MaskedGatherSDNode>(Op)->getExtensionType()
+ : cast<MaskedLoadSDNode>(Op)->getExtensionType();
+ if (ETy == ISD::ZEXTLOAD) {
+ EVT MemVT = cast<MemSDNode>(Op)->getMemoryVT();
+ KnownBits Known0(MemVT.getScalarSizeInBits());
+ return Known0.zext(BitWidth);
+ }
+ break;
+ }
case ISD::LOAD: {
LoadSDNode *LD = cast<LoadSDNode>(Op);
const Constant *Cst = TLI->getTargetConstantFromLoad(LD);
diff --git a/llvm/test/CodeGen/AArch64/sve-hadd.ll b/llvm/test/CodeGen/AArch64/sve-hadd.ll
index 857a883d80ea3d..978ee4534e5e1a 100644
--- a/llvm/test/CodeGen/AArch64/sve-hadd.ll
+++ b/llvm/test/CodeGen/AArch64/sve-hadd.ll
@@ -1347,10 +1347,8 @@ define void @zext_mload_avgflooru(ptr %p1, ptr %p2, <vscale x 8 x i1> %mask) {
; SVE: // %bb.0:
; SVE-NEXT: ld1b { z0.h }, p0/z, [x0]
; SVE-NEXT: ld1b { z1.h }, p0/z, [x1]
-; SVE-NEXT: eor z2.d, z0.d, z1.d
-; SVE-NEXT: and z0.d, z0.d, z1.d
-; SVE-NEXT: lsr z1.h, z2.h, #1
; SVE-NEXT: add z0.h, z0.h, z1.h
+; SVE-NEXT: lsr z0.h, z0.h, #1
; SVE-NEXT: st1h { z0.h }, p0, [x0]
; SVE-NEXT: ret
;
@@ -1377,11 +1375,11 @@ define void @zext_mload_avgceilu(ptr %p1, ptr %p2, <vscale x 8 x i1> %mask) {
; SVE-LABEL: zext_mload_avgceilu:
; SVE: // %bb.0:
; SVE-NEXT: ld1b { z0.h }, p0/z, [x0]
-; SVE-NEXT: ld1b { z1.h }, p0/z, [x1]
-; SVE-NEXT: eor z2.d, z0.d, z1.d
-; SVE-NEXT: orr z0.d, z0.d, z1.d
-; SVE-NEXT: lsr z1.h, z2.h, #1
-; SVE-NEXT: sub z0.h, z0.h, z1.h
+; SVE-NEXT: mov z1.h, #-1 // =0xffffffffffffffff
+; SVE-NEXT: ld1b { z2.h }, p0/z, [x1]
+; SVE-NEXT: eor z0.d, z0.d, z1.d
+; SVE-NEXT: sub z0.h, z2.h, z0.h
+; SVE-NEXT: lsr z0.h, z0.h, #1
; SVE-NEXT: st1b { z0.h }, p0, [x0]
; SVE-NEXT: ret
;
|
|
@llvm/pr-subscribers-backend-aarch64 Author: David Sherwood (david-arm) ChangesWe already support computing known bits for extending loads, but not for masked loads. For now I've only added support for zero-extends because that's the only thing currently tested. Even when the passthru value is poison we still know the top X bits are zero. Full diff: https://github.com/llvm/llvm-project/pull/115450.diff 2 Files Affected:
diff --git a/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp b/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
index 203e14f6cde3e3..901e63c47fac17 100644
--- a/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
+++ b/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
@@ -3920,6 +3920,19 @@ KnownBits SelectionDAG::computeKnownBits(SDValue Op, const APInt &DemandedElts,
Known.Zero.setBitsFrom(1);
break;
}
+ case ISD::MGATHER:
+ case ISD::MLOAD: {
+ ISD::LoadExtType ETy =
+ (Opcode == ISD::MGATHER)
+ ? cast<MaskedGatherSDNode>(Op)->getExtensionType()
+ : cast<MaskedLoadSDNode>(Op)->getExtensionType();
+ if (ETy == ISD::ZEXTLOAD) {
+ EVT MemVT = cast<MemSDNode>(Op)->getMemoryVT();
+ KnownBits Known0(MemVT.getScalarSizeInBits());
+ return Known0.zext(BitWidth);
+ }
+ break;
+ }
case ISD::LOAD: {
LoadSDNode *LD = cast<LoadSDNode>(Op);
const Constant *Cst = TLI->getTargetConstantFromLoad(LD);
diff --git a/llvm/test/CodeGen/AArch64/sve-hadd.ll b/llvm/test/CodeGen/AArch64/sve-hadd.ll
index 857a883d80ea3d..978ee4534e5e1a 100644
--- a/llvm/test/CodeGen/AArch64/sve-hadd.ll
+++ b/llvm/test/CodeGen/AArch64/sve-hadd.ll
@@ -1347,10 +1347,8 @@ define void @zext_mload_avgflooru(ptr %p1, ptr %p2, <vscale x 8 x i1> %mask) {
; SVE: // %bb.0:
; SVE-NEXT: ld1b { z0.h }, p0/z, [x0]
; SVE-NEXT: ld1b { z1.h }, p0/z, [x1]
-; SVE-NEXT: eor z2.d, z0.d, z1.d
-; SVE-NEXT: and z0.d, z0.d, z1.d
-; SVE-NEXT: lsr z1.h, z2.h, #1
; SVE-NEXT: add z0.h, z0.h, z1.h
+; SVE-NEXT: lsr z0.h, z0.h, #1
; SVE-NEXT: st1h { z0.h }, p0, [x0]
; SVE-NEXT: ret
;
@@ -1377,11 +1375,11 @@ define void @zext_mload_avgceilu(ptr %p1, ptr %p2, <vscale x 8 x i1> %mask) {
; SVE-LABEL: zext_mload_avgceilu:
; SVE: // %bb.0:
; SVE-NEXT: ld1b { z0.h }, p0/z, [x0]
-; SVE-NEXT: ld1b { z1.h }, p0/z, [x1]
-; SVE-NEXT: eor z2.d, z0.d, z1.d
-; SVE-NEXT: orr z0.d, z0.d, z1.d
-; SVE-NEXT: lsr z1.h, z2.h, #1
-; SVE-NEXT: sub z0.h, z0.h, z1.h
+; SVE-NEXT: mov z1.h, #-1 // =0xffffffffffffffff
+; SVE-NEXT: ld1b { z2.h }, p0/z, [x1]
+; SVE-NEXT: eor z0.d, z0.d, z1.d
+; SVE-NEXT: sub z0.h, z2.h, z0.h
+; SVE-NEXT: lsr z0.h, z0.h, #1
; SVE-NEXT: st1b { z0.h }, p0, [x0]
; SVE-NEXT: ret
;
|
paulwalker-arm
approved these changes
Nov 8, 2024
There was a problem hiding this comment.
As mentioned on #115142, I don't think the existing handling (or documentation) of the passthru parameter is strict enough to reinforce the assumption in the commit message. I do agree with your interpretation though.
Groverkss
pushed a commit
to iree-org/llvm-project
that referenced
this pull request
Nov 15, 2024
…Bits (llvm#115450) We already support computing known bits for extending loads, but not for masked loads. For now I've only added support for zero-extends because that's the only thing currently tested. Even when the passthru value is poison we still know the top X bits are zero.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We already support computing known bits for extending loads, but not for masked loads. For now I've only added support for zero-extends because that's the only thing currently tested. Even when the passthru value is poison we still know the top X bits are zero.