================
@@ -0,0 +1,27 @@
+// RUN: cir-opt %s -cir-to-llvm -o - | FileCheck %s
+
+// Contract test for CIRToLLVMLLVMIntrinsicCallOpLowering: the op def
+// declares Optional<CIR_AnyType>:$result, so the lowering must accept
+// 0-result (void) calls in addition to the single-result case.
+
+!s32i = !cir.int<s, 32>
+
+module {
+ // 0-result, 0-operand.
+ // CHECK-LABEL: llvm.func @void_no_operands
+ // CHECK: llvm.call_intrinsic "llvm.donothing"() : () -> ()
+ // CHECK: llvm.return
+ cir.func @void_no_operands() {
+ cir.call_llvm_intrinsic "donothing" : () -> ()
----------------
andykaylor wrote:
How did you get into this situation? We have existing builtin handlers that
call LLVM intrinsics with a void return type, and they're implemented using an
explicit void type. For example:
```
void test_lfence(void) {
__builtin_ia32_lfence();
}
```
Produces this CIR:
```
!void = !cir.void
cir.func @test_lfence() {
%0 = cir.call_llvm_intrinsic "x86.sse2.lfence" : () -> !void
cir.return loc(#loc2)
}
```
Which lowers to this LLVM IR:
```
define dso_local void @test_lfence() {
call void @llvm.x86.sse2.lfence()
ret void
}
```
https://github.com/llvm/llvm-project/pull/199516
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
