[llvm] 9b2fc66 - [SDAG] Harden assumption in getMemsetStringVal (#126207)
via llvm-commits
llvm-commits at lists.llvm.org
Thu Feb 13 00:48:09 PST 2025
Author: Cullen Rhodes
Date: 2025-02-13T08:48:06Z
New Revision: 9b2fc66830b2e81d95ef272ddc51c6cff9ba23a1
URL: https://github.com/llvm/llvm-project/commit/9b2fc66830b2e81d95ef272ddc51c6cff9ba23a1
DIFF: https://github.com/llvm/llvm-project/commit/9b2fc66830b2e81d95ef272ddc51c6cff9ba23a1.diff
LOG: [SDAG] Harden assumption in getMemsetStringVal (#126207)
In 5235973ee03aca4148ecabe5eff64da2af1e034e, an ICE was fixed in
getMemsetStringVal where f128 wasn't handled. It was noted at the time
[1] that the code below this also looks suspect, since it assumes the
element type of VT is either an f32 or f64.
This part of getMemsetStringVal relates to memcpy operations where the
source is a copy from a zero constant. The VT in question is determined
by TargetLowering::findOptimalMemOpLowering, which in turn calls a
further TLI hook getOptimalMemOpType.
For AArch64, getOptimalMemOpType returns either a v16i8, f128, i64, i32
or Other. For Other, TargetLowering::findOptimalMemOpLowering will then
pick an integer VT. So on AArch64 at least, I don't believe the suspect
code can be reached.
For other targets, ARM and x86 are the only ones that return a FP vector
type from getOptimalMemOpType. For both targets, the only such type is
v2f64, but given f64 is already handled it should also be fine.
To defend this, I considered adding an assert as mentioned in [1], but
given getConstantFP handles vector types, I figured using this to fully
handle the FP types makes the code simpler and more robust.
For test coverage I added unreachables to both of the branches handling
FP types in this code, but found neither fired with check-llvm across
all targets.
Test coverage was added to llvm/test/CodeGen/AArch64/memcpy-f128.ll in
5235973ee03aca4148ecabe5eff64da2af1e034e to defend ICE on f128, but at
some point it stopped hitting this code.
AArch64TargetLowering::getOptimalMemOpType was updated in
29200611055f49a0d37243caa5f8bba1df9d57a6, so I suspect this is when it
happened, although I haven't verified this. Although I did find by
updating the test to disable NEON, getOptimalMemOpType returns an f128
and the branch is once again hit.
For the final branch noted as suspect in [1], as far as I can tell this
has never had any test coverage, so I've added a test to the ARM backend
for this.
Fixes: https://github.com/llvm/llvm-project/issues/20521 [1]
Added:
Modified:
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
Removed:
################################################################################
diff --git a/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp b/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
index 164493d6dd860..9d2f87497d6fa 100644
--- a/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
+++ b/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
@@ -8015,17 +8015,8 @@ static SDValue getMemsetStringVal(EVT VT, const SDLoc &dl, SelectionDAG &DAG,
if (Slice.Array == nullptr) {
if (VT.isInteger())
return DAG.getConstant(0, dl, VT);
- if (VT == MVT::f32 || VT == MVT::f64 || VT == MVT::f128)
- return DAG.getConstantFP(0.0, dl, VT);
- if (VT.isVector()) {
- unsigned NumElts = VT.getVectorNumElements();
- MVT EltVT = (VT.getVectorElementType() == MVT::f32) ? MVT::i32 : MVT::i64;
- return DAG.getNode(ISD::BITCAST, dl, VT,
- DAG.getConstant(0, dl,
- EVT::getVectorVT(*DAG.getContext(),
- EltVT, NumElts)));
- }
- llvm_unreachable("Expected type!");
+ return DAG.getNode(ISD::BITCAST, dl, VT,
+ DAG.getConstant(0, dl, VT.changeTypeToInteger()));
}
assert(!VT.isVector() && "Can't handle vector type here!");
More information about the llvm-commits
mailing list