[X86] Explicitly widen larger than v4f16 to the legal v8f16 (NFC) #153839
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
|
@llvm/pr-subscribers-backend-x86 Author: Adam Nemet (anemet) ChangesThis patch makes the current behavior explicit to prepare for adding VTs for v[567]f16. Right now these types are EVTs and hence don't fall under getPreferredVectorAction and are simply widened to the next legal power-of-two vector type. For SSE2 this is v8f16. Without the preparatory patch however, the behavior would change after adding these types. getPreferredVectorAction would try to split them because this is the current behavior for any f16 vector type that is not legal. There is a lot more detail at The patch ensures that after the new types are added they would continue to be widened rather than split. Once the patch to enable v[567]f16 lands, it will be an NFC for x86. Full diff: https://github.com/llvm/llvm-project/pull/153839.diff 2 Files Affected:
diff --git a/llvm/lib/Target/X86/X86ISelLowering.cpp b/llvm/lib/Target/X86/X86ISelLowering.cpp
index 97cdf5b784bc0..98a4f3556069a 100644
--- a/llvm/lib/Target/X86/X86ISelLowering.cpp
+++ b/llvm/lib/Target/X86/X86ISelLowering.cpp
@@ -2756,8 +2756,10 @@ X86TargetLowering::getPreferredVectorAction(MVT VT) const {
!Subtarget.hasBWI())
return TypeSplitVector;
+ // Since v8f16 is legal, widen anything over v4f16.
if (!VT.isScalableVector() && VT.getVectorNumElements() != 1 &&
- !Subtarget.hasF16C() && VT.getVectorElementType() == MVT::f16)
+ VT.getVectorNumElements() <= 4 && !Subtarget.hasF16C() &&
+ VT.getVectorElementType() == MVT::f16)
return TypeSplitVector;
if (!VT.isScalableVector() && VT.getVectorNumElements() != 1 &&
diff --git a/llvm/test/CodeGen/X86/v7f16-crash.ll b/llvm/test/CodeGen/X86/v7f16-crash.ll
new file mode 100644
index 0000000000000..6db3e555028cc
--- /dev/null
+++ b/llvm/test/CodeGen/X86/v7f16-crash.ll
@@ -0,0 +1,14 @@
+; RUN: llc < %s -mtriple=x86_64-unknown-unknown-eabi-elf | FileCheck %s
+
+; CHECK-LABEL: conv2d
+define dso_local void @conv2d() {
+.preheader:
+ br label %0
+
+0: ; preds = %0, %.preheader
+ %1 = phi [4 x <7 x half>] [ zeroinitializer, %.preheader ], [ %4, %0 ]
+ %2 = extractvalue [4 x <7 x half>] %1, 0
+ %3 = extractvalue [4 x <7 x half>] %1, 1
+ %4 = insertvalue [4 x <7 x half>] poison, <7 x half> poison, 3
+ br label %0
+}
|
phoebewang
reviewed
Aug 16, 2025
llvm/test/CodeGen/X86/v7f16-crash.ll
Outdated
There was a problem hiding this comment.
Use pr152150.ll as the name.
This patch makes the current behavior explicit to prepare for adding VTs for v[567]f16. Right now these types are EVTs and hence don't fall under getPreferredVectorAction and are simply widened to the next legal power-of-two vector type. For SSE2 this is v8f16. Without the preparatory patch however, the behavior would change after adding these types. getPreferredVectorAction would try to split them because this is the current behavior for any f16 vector type that is not legal. There is a lot more detail at llvm#152150 in particular how splitting these new types leads to an inconsistency between NumRegistersForVT and getTypeAction. The patch ensures that after the new types are added they would continue to be widened rather than split. Once the patch to enable v[567]f16 lands, it will be an NFC for x86.
anemet
force-pushed
the
dev/anemet/x86-fail
branch
from
bc3fae1 to
355d1fc
Compare
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/169/builds/14131 Here is the relevant piece of the build log for the reference |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
This patch makes the current behavior explicit to prepare for adding VTs for v[567]f16.
Right now these types are EVTs and hence don't fall under getPreferredVectorAction and are simply widened to the next legal power-of-two vector type. For SSE2 this is v8f16.
Without the preparatory patch however, the behavior would change after adding these types. getPreferredVectorAction would try to split them because this is the current behavior for any f16 vector type that is not legal.
There is a lot more detail at
#152150 in particular how splitting these new types leads to an inconsistency between NumRegistersForVT and getTypeAction.
The patch ensures that after the new types are added they would continue to be widened rather than split. Once the patch to enable v[567]f16 lands, it will be an NFC for x86.