[FastISel] Lower call instruction with illegal type returned by LuoYuanke · Pull Request #180322 · llvm/llvm-project

LuoYuanke · 2026-02-07T06:04:51Z

Fix issue #179100
When lowering the call instruction with illegal type returned, we should
bail out and transfer the lowering to DAG. Otherwise the return value is
not promoted to proper type, but DAG would assume it has been promoted.

llvmbot · 2026-02-07T06:05:22Z

@llvm/pr-subscribers-llvm-selectiondag

@llvm/pr-subscribers-backend-x86

Author: Luo Yuanke (LuoYuanke)

Changes

Full diff: https://github.com/llvm/llvm-project/pull/180322.diff

2 Files Affected:

(modified) llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp (+8-2)
(added) llvm/test/CodeGen/X86/fast-isel-v4i1.ll (+27)

diff --git a/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp b/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
index 27131e14141cc..3010c4e6430f2 100644
--- a/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
+++ b/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
@@ -2019,8 +2019,14 @@ SDValue SelectionDAGBuilder::getValueImpl(const Value *V) {
 
     std::optional<CallingConv::ID> CallConv;
     auto *CB = dyn_cast<CallBase>(Inst);
-    if (CB && !CB->isInlineAsm())
-      CallConv = CB->getCallingConv();
+
+    if (CB && !CB->isInlineAsm()) {
+      if (Inst->getType()->isFirstClassType()) {
+        EVT VT = TLI.getValueType(DAG.getDataLayout(), Inst->getType());
+        if (!TLI.isTypeLegal(VT))
+          CallConv = CB->getCallingConv();
+      }
+    }
 
     RegsForValue RFV(*DAG.getContext(), TLI, DAG.getDataLayout(), InReg,
                      Inst->getType(), CallConv);
diff --git a/llvm/test/CodeGen/X86/fast-isel-v4i1.ll b/llvm/test/CodeGen/X86/fast-isel-v4i1.ll
new file mode 100644
index 0000000000000..2e9a26a93d507
--- /dev/null
+++ b/llvm/test/CodeGen/X86/fast-isel-v4i1.ll
@@ -0,0 +1,27 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py UTC_ARGS: --version 6
+; RUN: llc --fast-isel < %s -mtriple=x86_64-unknown-unknown | FileCheck %s
+
+define fastcc i16 @test() #0 nounwind {
+; CHECK-LABEL: test:
+; CHECK:       # %bb.0: # %entry
+; CHECK-NEXT:    pushq %rax
+; CHECK-NEXT:    xorl %eax, %eax
+; CHECK-NEXT:    vpxor %xmm0, %xmm0, %xmm0
+; CHECK-NEXT:    xorl %edi, %edi
+; CHECK-NEXT:    callq *%rax
+; CHECK-NEXT:    vpslld $31, %xmm0, %xmm0
+; CHECK-NEXT:    xorl %eax, %eax
+; CHECK-NEXT:    xorl %edi, %edi
+; CHECK-NEXT:    vpmovd2m %xmm0, %k0
+; CHECK-NEXT:    vpxor %xmm0, %xmm0, %xmm0
+; CHECK-NEXT:    vpmovm2d %k0, %xmm1
+; CHECK-NEXT:    callq *%rax
+; CHECK-NEXT:    popq %rcx
+; CHECK-NEXT:    retq
+entry:
+  %0 = call fastcc <4 x i1> null(ptr null, <4 x i1> zeroinitializer)
+  %1 = call fastcc i16 null(ptr null, <4 x i1> zeroinitializer, <4 x i1> %0)
+  ret i16 %1
+}
+
+attributes #0 = { "target-cpu"="znver5" }

arsenm · 2026-02-07T08:27:57Z

llvm/test/CodeGen/X86/fast-isel-v4i1.ll

Avoid UB in tests, and use named values

arsenm · 2026-02-07T08:28:09Z

llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp

The type legality should not be a factor here

github-actions · 2026-02-08T02:55:04Z

✅ With the latest revision this PR passed the undef deprecator.

When lowering the call instruction with illegal type returned, we should bail out and transfer the lowering to DAG. Otherwise the return value is not promoted to proper type, but DAG would assume it has been promoted.

arsenm · 2026-02-08T08:33:41Z

llvm/lib/Target/X86/X86FastISel.cpp

This logic kind of makes sense, but this is too narrow, and I would expect would already logically happen. Why wouldn't the same apply for the input arguments? I thought fast isel already gave up on illegally typed operations, so why does this need a new special case?

The input arguments are checked at https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86FastISel.cpp#L3306

https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/Mips/MipsFastISel.cpp#L1528 is how MIPS handle return type.

I wouldn't use mips as a reference on how to do anything

nikic · 2026-02-08T08:56:52Z

Is this fixing #179100? If so, please reference it in the PR description.

LuoYuanke · 2026-02-09T06:39:08Z

Is this fixing #179100? If so, please reference it in the PR description.

Done

llvm/lib/Target/X86/X86FastISel.cpp

Co-authored-by: Craig Topper <craig.topper@sifive.com>

github-actions · 2026-02-10T07:03:00Z

✅ With the latest revision this PR passed the C/C++ code formatter.

RKSimon · 2026-02-17T14:28:15Z

llvm/test/CodeGen/X86/fast-isel-v4i1.ll

I'd prefer this test file was called pr179100.ll for better reference

arsenm · 2026-02-18T10:58:35Z

llvm/lib/Target/X86/X86FastISel.cpp

Probably should be processing the processed return type, instead of this. AArch64 example:

llvm-project/llvm/lib/Target/AArch64/AArch64FastISel.cpp

Line 3201 in 3d3ad01

if (!isTypeLegal(Val->getType(), VT) &&

I think CLI.OutVals is not the returned values. X86 has code to check it at https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86FastISel.cpp#L3306

alexrp · 2026-03-09T01:05:44Z

Friendly ping on reviews since the bug this is fixing will be a problem for Zig's LLVM 22 upgrade.

LuoYuanke · 2026-03-09T01:10:01Z

ping

phoebewang

LGTM.

phoebewang · 2026-03-09T02:09:21Z

llvm/test/CodeGen/X86/bf16-fast-isel.ll

These are redundant but functional correct. I think it's not a big problem for fast isel.

LuoYuanke · 2026-03-09T09:17:41Z

I think the required change from @arsenm has been addressed. I'll land the patch if there is no objection.

nikic · 2026-03-10T08:10:29Z

For the record, this causes an -O0 compile-time regression for tramp3d-v4: https://llvm-compile-time-tracker.com/compare.php?from=351d900e6c96ee51cbb40c933969b5ebd15a4122&to=41ef3d083a0925cb9c184057f76a0d42ad5680ab&stat=instructions:u I assume it often uses some illegal type for returns, but I haven't checked what it is. My guess would be i1.

LuoYuanke · 2026-03-12T00:58:32Z

For the record, this causes an -O0 compile-time regression for tramp3d-v4: https://llvm-compile-time-tracker.com/compare.php?from=351d900e6c96ee51cbb40c933969b5ebd15a4122&to=41ef3d083a0925cb9c184057f76a0d42ad5680ab&stat=instructions:u I assume it often uses some illegal type for returns, but I haven't checked what it is. My guess would be i1.

Switching from fast ISel to DAG ISel would spent more compile-time on ISel. The i1 return type is promoted to i8 which is the same in ISel promotion. The bf16 return type is bf16, while it is promoted to f32 in ISel. Maybe we can check if the promoted type is the same to abi return type before switching form fast ISel to DAG ISel.

…0322) Fix issue llvm#179100 When lowering the call instruction with illegal type returned, we should bail out and transfer the lowering to DAG. Otherwise the return value is not promoted to proper type, but DAG would assume it has been promoted. --------- Co-authored-by: Yuanke Luo <ykluo@birentech.com> (cherry picked from commit 41ef3d0)

LuoYuanke · 2026-03-16T01:54:15Z

I create a PR (#186723) to improve the compile-time.

…lvm#180322)" This reverts commit 4dfb4b6.

…lvm#180322)" This reverts commit 4dfb4b6. This causes a large compile-time regression for debug builds.

llvmbot added backend:X86 llvm:SelectionDAG SelectionDAGISel as well labels Feb 7, 2026

LuoYuanke mentioned this pull request Feb 7, 2026

[X86][SelectionDAG] Register type affect DAG ISel #179446

Open

arsenm requested changes Feb 7, 2026

View reviewed changes

LuoYuanke force-pushed the fastISel-v4i1 branch from 1a67704 to 447762b Compare February 8, 2026 02:53

LuoYuanke changed the title ~~[FastISel] Get right type for value from fast isel~~ [FastISel] Lower call instruction with illegal type returned Feb 8, 2026

LuoYuanke requested review from RKSimon, alexrp, phoebewang and woruyu February 8, 2026 02:56

LuoYuanke force-pushed the fastISel-v4i1 branch from 447762b to eab7476 Compare February 8, 2026 02:59

LuoYuanke requested a review from arsenm February 8, 2026 03:06

[FastISel] Lower call instruction with illegal type returned

b25aea6

When lowering the call instruction with illegal type returned, we should bail out and transfer the lowering to DAG. Otherwise the return value is not promoted to proper type, but DAG would assume it has been promoted.

LuoYuanke force-pushed the fastISel-v4i1 branch from eab7476 to b25aea6 Compare February 8, 2026 03:24

arsenm reviewed Feb 8, 2026

View reviewed changes

LuoYuanke requested a review from arsenm February 10, 2026 03:48

topperc reviewed Feb 10, 2026

View reviewed changes

llvm/lib/Target/X86/X86FastISel.cpp Outdated Show resolved Hide resolved

Update llvm/lib/Target/X86/X86FastISel.cpp

8506989

Co-authored-by: Craig Topper <craig.topper@sifive.com>

Fix clang format issue

b54ebeb

LuoYuanke requested a review from topperc February 10, 2026 07:19

RKSimon reviewed Feb 17, 2026

View reviewed changes

Rename test cases

b637407

RKSimon self-requested a review February 18, 2026 09:38

arsenm reviewed Feb 18, 2026

View reviewed changes

LuoYuanke requested a review from arsenm March 9, 2026 01:09

phoebewang approved these changes Mar 9, 2026

View reviewed changes

LuoYuanke merged commit 41ef3d0 into llvm:main Mar 10, 2026
10 checks passed

LuoYuanke deleted the fastISel-v4i1 branch March 10, 2026 03:56

alexrp added this to the LLVM 22.x Release milestone Mar 10, 2026

github-project-automation bot added this to LLVM Release Status Mar 10, 2026

github-project-automation bot moved this to Needs Triage in LLVM Release Status Mar 10, 2026

github-project-automation bot moved this from Needs Triage to Done in LLVM Release Status Mar 10, 2026

nikic added a commit to rust-lang/llvm-project that referenced this pull request Mar 28, 2026

Revert "[FastISel] Lower call instruction with illegal type returned (l…

87baadf

…lvm#180322)" This reverts commit 4dfb4b6.

nikic added a commit to rust-lang/llvm-project that referenced this pull request Mar 28, 2026

Revert "[FastISel] Lower call instruction with illegal type returned (l…

1cb4e38

…lvm#180322)" This reverts commit 4dfb4b6. This causes a large compile-time regression for debug builds.

Conversation

LuoYuanke commented Feb 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

llvmbot commented Feb 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Feb 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nikic commented Feb 8, 2026

Uh oh!

LuoYuanke commented Feb 9, 2026

Uh oh!

Uh oh!

github-actions bot commented Feb 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexrp commented Mar 9, 2026

Uh oh!

LuoYuanke commented Mar 9, 2026

Uh oh!

phoebewang left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

LuoYuanke commented Mar 9, 2026

Uh oh!

Uh oh!

nikic commented Mar 10, 2026

Uh oh!

LuoYuanke commented Mar 12, 2026

Uh oh!

LuoYuanke commented Mar 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

LuoYuanke commented Feb 7, 2026 •

edited

Loading

llvmbot commented Feb 7, 2026 •

edited

Loading

github-actions bot commented Feb 8, 2026 •

edited

Loading

github-actions bot commented Feb 10, 2026 •

edited

Loading

LuoYuanke commented Mar 16, 2026 •

edited

Loading