Swift Calling Convention: add swiftcc

[manmanren]

Summary

Context can be found here:
RFC: Implementing the Swift calling convention in LLVM and Clang
https://groups.google.com/forum/#!topic/llvm-dev/epDd2w93kZ0

[manmanren]

Ping

[t.p.northover]

Hi Manman,

I think the testing is too weak if we're going for ABI stability (particularly based on FastCC, which is explicitly called out in the LangRef as unstable and based on APCS). I'd actually strongly suggest Swift starts out with AAPCS_VFP on ARM.

Even with that, I'd suggest testing things like minimum stack slot size, alignment of objects on the stack, whether everything goes on the stack if something has. Probably on both iOS and WatchOS because I suspect those details differ based on type alignment.

For x86, you don't seem to test the new xmm registers at all.

Cheers.

Tim.

lib/Target/X86/X86CallingConv.td

196–199 ↗

(On Diff #49764)

Why did you drop the CCIfType<[i1], CCPromoteToType<i8>>? Does Swift never return anything containing an i1 or something?

Probably worth commenting on the differences here too (adding R8, XMM2 and XMM3 it seems).

test/CodeGen/ARM/swift-ios.ll

8–13 ↗

(On Diff #49764)

I don't think this is needed. Same with the other tests.

[manmanren]

Separate this patch into X86 and ARM. This is the updated version for X86.

Cheers,
Manman

[manmanren]

In D17863#371104, @t.p.northover wrote:

Hi Manman,

I think the testing is too weak if we're going for ABI stability (particularly based on FastCC, which is explicitly called out in the LangRef as unstable and based on APCS). I'd actually strongly suggest Swift starts out with AAPCS_VFP on ARM.

I will update the ARM patch to base on AAPCS_VFP.

Even with that, I'd suggest testing things like minimum stack slot size, alignment of objects on the stack, whether everything goes on the stack if something has. Probably on both iOS and WatchOS because I suspect those details differ based on type alignment.

For x86, you don't seem to test the new xmm registers at all.

For x86, added tests for xmm and i1.

Cheers,
Manman

lib/Target/X86/X86CallingConv.td

196–199 ↗

(On Diff #52589)

Hi Tim,

i1 type is promoted to i8 before reaching here. That is why we don't need to handle i1 here.
This is what other RetCCs do, such as RetCC_X86_32_Fast, but I am not against making it explicit here.

[t.p.northover]

lib/Target/X86/X86CallingConv.td

196–199 ↗

(On Diff #52589)

Where does it get promoted? To me it looks like RetCC_X86_64 directly calls RetCC_X86_64_Swift, which doesn't handle it. It then gets forwarded to RetCC_X86Common which promotes to i8 and only uses AL, DL, CL.

I suspect you'll find that something like

define [4 x i1] @foo() {
    %res = insertvalue [4 x i1] undef, i1 true, 3
    ret [4 x i1] %res
}

does not do what you're expecting.

[manmanren]

lib/Target/X86/X86CallingConv.td

196–199 ↗

(On Diff #52589)

Sorry that it took so long for me to get back on this!

It was promoted in TargetLoweringBase::computeRegisterProperties

// Inspect all of the ValueType's smaller than the largest integer
// register to see which ones need promotion.

TLI.getRegisterType(...) for i1 will return i8.

[t.p.northover]

lib/Target/X86/X86CallingConv.td

196–199 ↗

(On Diff #52589)

Ah, I see. The i1 case is only needed for AVX-512 by the looks of it. Do you know if Swift has a position on that? I would expect the Linux crowd to want to try it out when the chips come along properly, even if Macs don't have them yet.

[rjmccall]

lib/Target/X86/X86CallingConv.td

196–199 ↗

(On Diff #52589)

Steve Canon and I agreed that the swift CC should be stable independent of AVX settings, so you shouldn't ever see vectors larger than 16 bytes in backend lowering.

[t.p.northover]

lib/Target/X86/X86CallingConv.td

196–199 ↗

(On Diff #52589)

Enabling AVX-512 makes i1 a legal type which affects the CC even for plain i1s (well, if they'd get passed in r8b). E.g. compiling my example with "-mcpu=skylake-avx512" changes the calling convention to indirect sret.

[manmanren]

@Tim,

Do you have any other comment?

Thanks,
Manman

lib/Target/X86/X86CallingConv.td

196–199 ↗

(On Diff #52589)

Yes, enabling AVX512 will make i1 a legal type. I wonder how other calling conventions (RetCC_X86_64_HiPE, RetCC_X86_64_WebKit_JS, RetCC_X86_32_Fast) do not need to handle i1.

I will add this line
CCIfType<[i1], CCPromoteToType<i8>>,

[t.p.northover]

No other comments, the changes look pretty straightforward to me.

Tim.

lib/Target/X86/X86CallingConv.td

196–199 ↗

(On Diff #52589)

At least WebKit and Fast have no concerns about ABI stability. Not sure about HiPE.

[rjmccall]

lib/Target/X86/X86CallingConv.td

196–199 ↗

(On Diff #52589)

That is true for the C calling convention; it is not true for swiftcc. swiftcc will always treat a 512-bit vector as illegal and split it up. If we have an ABI break in the future that allows us to assume the existence of AVX, we can easily revisit that decision; but I specifically did not want to use the unstable C rule for swift.

[t.p.northover]

lib/Target/X86/X86CallingConv.td

196–199 ↗

(On Diff #52589)

Which bit? I don't think anyone's mentioned passing actual vectors; this is an issue with scalar i1s being handled differently depending on whether AVX-512 is around or not.

[manmanren]

lib/Target/X86/X86CallingConv.td

196–199 ↗

(On Diff #52589)

John,

I think we are probably talking about different things here. Tim was concerned that if we pass i1 as the 4th integer, it will not be passed in r8b. Because I didn't add "CCIfType<[i1], CCPromoteToType<i8>>," right before "CCIfType<[i8] , CCAssignToReg<[AL, DL, CL, R8B]>>", if we have an i1 reaching the code path here, it will fall to the common RetCC for X86.

I didn't include that line because other calling conventions did not and I thought we would not have i1 reaching here. It turns out that when we enable AVX512, we will actually have i1 reaching here.

Clang also may do something for i1 so it is possible that with clang, we will not have i1 reaching here, but it does not hurt to include it here :]

[manmanren]

Adding handling of i1.

[t.p.northover]

Looks good, thanks Manman!

llvm/trunk/docs/BitCodeFormat.rst

 * *callingconv*: The calling convention number:
   * ``ccc``: code 0
   * ``fastcc``: code 8
   * ``coldcc``: code 9
   * ``webkit_jscc``: code 12
   * ``anyregcc``: code 13
   * ``preserve_mostcc``: code 14
   * ``preserve_allcc``: code 15
+  * ``swiftcc`` : code 16
   * ``cxx_fast_tlscc``: code 17
   * ``x86_stdcallcc``: code 64
   * ``x86_fastcallcc``: code 65
   * ``arm_apcscc``: code 66
   * ``arm_aapcscc``: code 67
   * ``arm_aapcs_vfpcc``: code 68
 
 * isproto*: Non-zero if this entry represents a declaration rather than a

llvm/trunk/docs/LangRef.rst

"``cxx_fast_tlscc``" - The `CXX_FAST_TLS` calling convention for access functions
     how arguments and return values are passed, but it uses a different set of
     caller/callee-saved registers.
 
     Given that each platform has its own lowering sequence, hence its own set
     of preserved registers, we can't use the existing `PreserveMost`.
 
     - On X86-64 the callee preserves all general purpose registers, except for
       RDI and RAX.
+"``swiftcc``" - This calling convention is used for Swift language.
+    - On X86-64 RCX and R8 are available for additional integer returns, and
+      XMM2 and XMM3 are available for additional FP/vector returns.
 "``cc <n>``" - Numbered convention
     Any calling convention may be specified by number, allowing
     target-specific calling conventions to be used. Target specific
     calling conventions start at 64.
 
 More calling conventions can be added/defined on an as-needed basis, to
 support Pascal conventions or any other well-known target-independent
 convention.

llvm/trunk/lib/AsmParser/LLLexer.cpp

#define KEYWORD(STR)                                                           \
   KEYWORD(ptx_kernel);
   KEYWORD(ptx_device);
   KEYWORD(spir_kernel);
   KEYWORD(spir_func);
   KEYWORD(intel_ocl_bicc);
   KEYWORD(x86_64_sysvcc);
   KEYWORD(x86_64_win64cc);
   KEYWORD(webkit_jscc);
+  KEYWORD(swiftcc);
   KEYWORD(anyregcc);
   KEYWORD(preserve_mostcc);
   KEYWORD(preserve_allcc);
   KEYWORD(ghccc);
   KEYWORD(x86_intrcc);
   KEYWORD(hhvmcc);
   KEYWORD(hhvm_ccc);
   KEYWORD(cxx_fast_tlscc);

llvm/trunk/lib/AsmParser/LLParser.cpp

 ///   ::= 'spir_kernel'
 ///   ::= 'x86_64_sysvcc'
 ///   ::= 'x86_64_win64cc'
 ///   ::= 'webkit_jscc'
 ///   ::= 'anyregcc'
 ///   ::= 'preserve_mostcc'
 ///   ::= 'preserve_allcc'
 ///   ::= 'ghccc'
+///   ::= 'swiftcc'
 ///   ::= 'x86_intrcc'
 ///   ::= 'hhvmcc'
 ///   ::= 'hhvm_ccc'
 ///   ::= 'cxx_fast_tlscc'
 ///   ::= 'cc' UINT
 ///
 bool LLParser::ParseOptionalCallingConv(unsigned &CC) {
   switch (Lex.getKind()) {
bool LLParser::ParseOptionalCallingConv(unsigned &CC) {
   case lltok::kw_intel_ocl_bicc: CC = CallingConv::Intel_OCL_BI; break;
   case lltok::kw_x86_64_sysvcc:  CC = CallingConv::X86_64_SysV; break;
   case lltok::kw_x86_64_win64cc: CC = CallingConv::X86_64_Win64; break;
   case lltok::kw_webkit_jscc:    CC = CallingConv::WebKit_JS; break;
   case lltok::kw_anyregcc:       CC = CallingConv::AnyReg; break;
   case lltok::kw_preserve_mostcc:CC = CallingConv::PreserveMost; break;
   case lltok::kw_preserve_allcc: CC = CallingConv::PreserveAll; break;
   case lltok::kw_ghccc:          CC = CallingConv::GHC; break;
+  case lltok::kw_swiftcc:        CC = CallingConv::Swift; break;
   case lltok::kw_x86_intrcc:     CC = CallingConv::X86_INTR; break;
   case lltok::kw_hhvmcc:         CC = CallingConv::HHVM; break;
   case lltok::kw_hhvm_ccc:       CC = CallingConv::HHVM_C; break;
   case lltok::kw_cxx_fast_tlscc: CC = CallingConv::CXX_FAST_TLS; break;
   case lltok::kw_cc: {
       Lex.Lex();
       return ParseUInt32(CC);
     }

llvm/trunk/lib/AsmParser/LLToken.h

enum Kind {
     kw_x86_stdcallcc, kw_x86_fastcallcc, kw_x86_thiscallcc, kw_x86_vectorcallcc,
     kw_arm_apcscc, kw_arm_aapcscc, kw_arm_aapcs_vfpcc,
     kw_msp430_intrcc,
     kw_avr_intrcc, kw_avr_signalcc,
     kw_ptx_kernel, kw_ptx_device,
     kw_spir_kernel, kw_spir_func,
     kw_x86_64_sysvcc, kw_x86_64_win64cc,
     kw_webkit_jscc, kw_anyregcc,
+    kw_swiftcc,
     kw_preserve_mostcc, kw_preserve_allcc,
     kw_ghccc,
     kw_x86_intrcc,
     kw_hhvmcc, kw_hhvm_ccc,
     kw_cxx_fast_tlscc,
 
     // Attributes:
     kw_attributes,

llvm/trunk/lib/IR/AsmWriter.cpp

static void PrintCallingConv(unsigned cc, raw_ostream &Out) {
   case CallingConv::AVR_INTR:      Out << "avr_intrcc "; break;
   case CallingConv::AVR_SIGNAL:    Out << "avr_signalcc "; break;
   case CallingConv::PTX_Kernel:    Out << "ptx_kernel"; break;
   case CallingConv::PTX_Device:    Out << "ptx_device"; break;
   case CallingConv::X86_64_SysV:   Out << "x86_64_sysvcc"; break;
   case CallingConv::X86_64_Win64:  Out << "x86_64_win64cc"; break;
   case CallingConv::SPIR_FUNC:     Out << "spir_func"; break;
   case CallingConv::SPIR_KERNEL:   Out << "spir_kernel"; break;
+  case CallingConv::Swift:         Out << "swiftcc"; break;
   case CallingConv::X86_INTR:      Out << "x86_intrcc"; break;
   case CallingConv::HHVM:          Out << "hhvmcc"; break;
   case CallingConv::HHVM_C:        Out << "hhvm_ccc"; break;
   }
 }
 
 // PrintEscapedString - Print each character of the specified string, escaping
 // it if it is not printable or if it is an escape char.

llvm/trunk/lib/Target/X86/X86CallingConv.td

 def RetCC_X86_64_WebKit_JS : CallingConv<[
   // Promote all types to i64
   CCIfType<[i8, i16, i32], CCPromoteToType<i64>>,
 
   // Return: RAX
   CCIfType<[i64], CCAssignToReg<[RAX]>>
 ]>;
 
+def RetCC_X86_64_Swift : CallingConv<[
+  // For integers, ECX, R8D can be used as extra return registers.
+  CCIfType<[i1],  CCPromoteToType<i8>>,
+  CCIfType<[i8] , CCAssignToReg<[AL, DL, CL, R8B]>>,
+  CCIfType<[i16], CCAssignToReg<[AX, DX, CX, R8W]>>,
+  CCIfType<[i32], CCAssignToReg<[EAX, EDX, ECX, R8D]>>,
+  CCIfType<[i64], CCAssignToReg<[RAX, RDX, RCX, R8]>>,
+
+  // XMM0, XMM1, XMM2 and XMM3 can be used to return FP values.
+  CCIfType<[f32], CCAssignToReg<[XMM0, XMM1, XMM2, XMM3]>>,
+  CCIfType<[f64], CCAssignToReg<[XMM0, XMM1, XMM2, XMM3]>>,
+  CCIfType<[f128], CCAssignToReg<[XMM0, XMM1, XMM2, XMM3]>>,
+
+  // MMX vector types are returned in XMM0, XMM1, XMM2 and XMM3.
+  CCIfType<[x86mmx], CCAssignToReg<[XMM0, XMM1, XMM2, XMM3]>>,
+  CCDelegateTo<RetCC_X86Common>
+]>;
+
 // X86-64 AnyReg return-value convention. No explicit register is specified for
 // the return-value. The register allocator is allowed and expected to choose
 // any free register.
 //
 // This calling convention is currently only supported by the stackmap and
 // patchpoint intrinsics. All other uses will result in an assert on Debug
 // builds. On Release builds we fallback to the X86 C calling convention.
 def RetCC_X86_64_AnyReg : CallingConv<[

 def RetCC_X86_64 : CallingConv<[
   // HiPE uses RetCC_X86_64_HiPE
   CCIfCC<"CallingConv::HiPE", CCDelegateTo<RetCC_X86_64_HiPE>>,
 
   // Handle JavaScript calls.
   CCIfCC<"CallingConv::WebKit_JS", CCDelegateTo<RetCC_X86_64_WebKit_JS>>,
   CCIfCC<"CallingConv::AnyReg", CCDelegateTo<RetCC_X86_64_AnyReg>>,
 
+  // Handle Swift calls.
+  CCIfCC<"CallingConv::Swift", CCDelegateTo<RetCC_X86_64_Swift>>,
+
   // Handle explicit CC selection
   CCIfCC<"CallingConv::X86_64_Win64", CCDelegateTo<RetCC_X86_Win64_C>>,
   CCIfCC<"CallingConv::X86_64_SysV", CCDelegateTo<RetCC_X86_64_C>>,
 
   // Handle HHVM calls.
   CCIfCC<"CallingConv::HHVM", CCDelegateTo<RetCC_X86_64_HHVM>>,
 
   // Mingw64 and native Win64 use Win64 CC

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

bool X86FastISel::fastLowerCall(CallLoweringInfo &CLI) {
   bool IsWin64        = Subtarget->isCallingConvWin64(CC);
 
   // Handle only C, fastcc, and webkit_js calling conventions for now.
   switch (CC) {
   default: return false;
   case CallingConv::C:
   case CallingConv::Fast:
   case CallingConv::WebKit_JS:
+  case CallingConv::Swift:
   case CallingConv::X86_FastCall:
   case CallingConv::X86_64_Win64:
   case CallingConv::X86_64_SysV:
     break;
   }
 
   // Allow SelectionDAG isel to handle tail calls.
   if (IsTailCall)

llvm/trunk/test/CodeGen/X86/swift-return.ll

+; RUN: llc -verify-machineinstrs < %s -mtriple=x86_64-unknown-unknown | FileCheck %s
+; RUN: llc -verify-machineinstrs < %s -mtriple=x86_64-unknown-unknown -O0 | FileCheck --check-prefix=CHECK-O0 %s
+
+@var = global i32 0
+
+; Test how llvm handles return type of {i16, i8}. The return value will be
+; passed in %eax and %dl.
+; CHECK-LABEL: test:
+; CHECK: movl %edi
+; CHECK: callq gen
+; CHECK: movsbl %dl
+; CHECK: addl %{{.*}}, %eax
+; CHECK-O0-LABEL: test
+; CHECK-O0: movl %edi
+; CHECK-O0: callq gen
+; CHECK-O0: movswl %ax
+; CHECK-O0: movsbl %dl
+; CHECK-O0: addl
+; CHECK-O0: movw %{{.*}}, %ax
+define i16 @test(i32 %key) {
+entry:
+  %key.addr = alloca i32, align 4
+  store i32 %key, i32* %key.addr, align 4
+  %0 = load i32, i32* %key.addr, align 4
+  %call = call swiftcc { i16, i8 } @gen(i32 %0)
+  %v3 = extractvalue { i16, i8 } %call, 0
+  %v1 = sext i16 %v3 to i32
+  %v5 = extractvalue { i16, i8 } %call, 1
+  %v2 = sext i8 %v5 to i32
+  %add = add nsw i32 %v1, %v2
+  %conv = trunc i32 %add to i16
+  ret i16 %conv
+}
+
+declare swiftcc { i16, i8 } @gen(i32)
+
+; If we can't pass every return value in register, we will pass everything
+; in memroy. The caller provides space for the return value and passes
+; the address in %rdi. The first input argument will be in %rsi.
+; CHECK-LABEL: test2:
+; CHECK: leaq (%rsp), %rdi
+; CHECK: movl %{{.*}}, %esi
+; CHECK: callq gen2
+; CHECK: movl (%rsp)
+; CHECK-DAG: addl 4(%rsp)
+; CHECK-DAG: addl 8(%rsp)
+; CHECK-DAG: addl 12(%rsp)
+; CHECK-DAG: addl 16(%rsp)
+; CHECK-O0-LABEL: test2:
+; CHECK-O0-DAG: leaq (%rsp), %rdi
+; CHECK-O0-DAG: movl {{.*}}, %esi
+; CHECK-O0: callq gen2
+; CHECK-O0-DAG: movl (%rsp)
+; CHECK-O0-DAG: movl 4(%rsp)
+; CHECK-O0-DAG: movl 8(%rsp)
+; CHECK-O0-DAG: movl 12(%rsp)
+; CHECK-O0-DAG: movl 16(%rsp)
+; CHECK-O0: addl
+; CHECK-O0: addl
+; CHECK-O0: addl
+; CHECK-O0: addl
+; CHECK-O0: movl %{{.*}}, %eax
+define i32 @test2(i32 %key) #0 {
+entry:
+  %key.addr = alloca i32, align 4
+  store i32 %key, i32* %key.addr, align 4
+  %0 = load i32, i32* %key.addr, align 4
+  %call = call swiftcc { i32, i32, i32, i32, i32 } @gen2(i32 %0)
+
+  %v3 = extractvalue { i32, i32, i32, i32, i32 } %call, 0
+  %v5 = extractvalue { i32, i32, i32, i32, i32 } %call, 1
+  %v6 = extractvalue { i32, i32, i32, i32, i32 } %call, 2
+  %v7 = extractvalue { i32, i32, i32, i32, i32 } %call, 3
+  %v8 = extractvalue { i32, i32, i32, i32, i32 } %call, 4
+
+  %add = add nsw i32 %v3, %v5
+  %add1 = add nsw i32 %add, %v6
+  %add2 = add nsw i32 %add1, %v7
+  %add3 = add nsw i32 %add2, %v8
+  ret i32 %add3
+}
+
+; The address of the return value is passed in %rdi.
+; On return, %rax will contain the adddress that has been passed in by the caller in %rdi.
+; CHECK-LABEL: gen2:
+; CHECK: movl %esi, 16(%rdi)
+; CHECK: movl %esi, 12(%rdi)
+; CHECK: movl %esi, 8(%rdi)
+; CHECK: movl %esi, 4(%rdi)
+; CHECK: movl %esi, (%rdi)
+; CHECK: movq %rdi, %rax
+; CHECK-O0-LABEL: gen2:
+; CHECK-O0-DAG: movl %esi, 16(%rdi)
+; CHECK-O0-DAG: movl %esi, 12(%rdi)
+; CHECK-O0-DAG: movl %esi, 8(%rdi)
+; CHECK-O0-DAG: movl %esi, 4(%rdi)
+; CHECK-O0-DAG: movl %esi, (%rdi)
+; CHECK-O0-DAG: movq %rdi, %rax
+define swiftcc { i32, i32, i32, i32, i32 } @gen2(i32 %key) {
+  %Y = insertvalue { i32, i32, i32, i32, i32 } undef, i32 %key, 0
+  %Z = insertvalue { i32, i32, i32, i32, i32 } %Y, i32 %key, 1
+  %Z2 = insertvalue { i32, i32, i32, i32, i32 } %Z, i32 %key, 2
+  %Z3 = insertvalue { i32, i32, i32, i32, i32 } %Z2, i32 %key, 3
+  %Z4 = insertvalue { i32, i32, i32, i32, i32 } %Z3, i32 %key, 4
+  ret { i32, i32, i32, i32, i32 } %Z4
+}
+
+; The return value {i32, i32, i32, i32} will be returned via registers %eax,
+; %edx, %ecx, %r8d.
+; CHECK-LABEL: test3:
+; CHECK: callq gen3
+; CHECK: addl %edx, %eax
+; CHECK: addl %ecx, %eax
+; CHECK: addl %r8d, %eax
+; CHECK-O0-LABEL: test3:
+; CHECK-O0: callq gen3
+; CHECK-O0: addl %edx, %eax
+; CHECK-O0: addl %ecx, %eax
+; CHECK-O0: addl %r8d, %eax
+define i32 @test3(i32 %key) #0 {
+entry:
+  %key.addr = alloca i32, align 4
+  store i32 %key, i32* %key.addr, align 4
+  %0 = load i32, i32* %key.addr, align 4
+  %call = call swiftcc { i32, i32, i32, i32 } @gen3(i32 %0)
+
+  %v3 = extractvalue { i32, i32, i32, i32 } %call, 0
+  %v5 = extractvalue { i32, i32, i32, i32 } %call, 1
+  %v6 = extractvalue { i32, i32, i32, i32 } %call, 2
+  %v7 = extractvalue { i32, i32, i32, i32 } %call, 3
+
+  %add = add nsw i32 %v3, %v5
+  %add1 = add nsw i32 %add, %v6
+  %add2 = add nsw i32 %add1, %v7
+  ret i32 %add2
+}
+
+declare swiftcc { i32, i32, i32, i32 } @gen3(i32 %key)
+
+; The return value {float, float, float, float} will be returned via registers
+; %xmm0, %xmm1, %xmm2, %xmm3.
+; CHECK-LABEL: test4:
+; CHECK: callq gen4
+; CHECK: addss %xmm1, %xmm0
+; CHECK: addss %xmm2, %xmm0
+; CHECK: addss %xmm3, %xmm0
+; CHECK-O0-LABEL: test4:
+; CHECK-O0: callq gen4
+; CHECK-O0: addss %xmm1, %xmm0
+; CHECK-O0: addss %xmm2, %xmm0
+; CHECK-O0: addss %xmm3, %xmm0
+define float @test4(float %key) #0 {
+entry:
+  %key.addr = alloca float, align 4
+  store float %key, float* %key.addr, align 4
+  %0 = load float, float* %key.addr, align 4
+  %call = call swiftcc { float, float, float, float } @gen4(float %0)
+
+  %v3 = extractvalue { float, float, float, float } %call, 0
+  %v5 = extractvalue { float, float, float, float } %call, 1
+  %v6 = extractvalue { float, float, float, float } %call, 2
+  %v7 = extractvalue { float, float, float, float } %call, 3
+
+  %add = fadd float %v3, %v5
+  %add1 = fadd float %add, %v6
+  %add2 = fadd float %add1, %v7
+  ret float %add2
+}
+
+declare swiftcc { float, float, float, float } @gen4(float %key)
+
+; CHECK-LABEL: consume_i1_ret:
+; CHECK: callq produce_i1_ret
+; CHECK: andb $1, %al
+; CHECK: andb $1, %dl
+; CHECK: andb $1, %cl
+; CHECK: andb $1, %r8b
+; CHECK-O0-LABEL: consume_i1_ret:
+; CHECK-O0: callq produce_i1_ret
+; CHECK-O0: andb $1, %al
+; CHECK-O0: andb $1, %dl
+; CHECK-O0: andb $1, %cl
+; CHECK-O0: andb $1, %r8b
+define void @consume_i1_ret() {
+  %call = call swiftcc { i1, i1, i1, i1 } @produce_i1_ret()
+  %v3 = extractvalue { i1, i1, i1, i1 } %call, 0
+  %v5 = extractvalue { i1, i1, i1, i1 } %call, 1
+  %v6 = extractvalue { i1, i1, i1, i1 } %call, 2
+  %v7 = extractvalue { i1, i1, i1, i1 } %call, 3
+  %val = zext i1 %v3 to i32
+  store i32 %val, i32* @var
+  %val2 = zext i1 %v5 to i32
+  store i32 %val2, i32* @var
+  %val3 = zext i1 %v6 to i32
+  store i32 %val3, i32* @var
+  %val4 = zext i1 %v7 to i32
+  store i32 %val4, i32* @var
+  ret void
+}
+
+declare swiftcc { i1, i1, i1, i1 } @produce_i1_ret()