Call result #​1 has unhandled type i16

[llvmbot]

Bugzilla Link	2212
Resolution	DUPLICATE
Resolved on	Nov 02, 2009 13:42
Version	trunk
OS	MacOS X
Reporter	LLVM Bugzilla Contributor
CC	@sunfishcode

Extended Description

---

target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128"
target triple = "x86_64-apple-darwin9.1.0"
%struct.S_6 = type { i8, i16 }

define %struct.S_6 @​bar() {
ret i8 1, i16 2
}

define i8 @​foo() {
%c = call %struct.S_6 @​bar()
%mrv_gr = getresult %struct.S_6 %c, 0
ret i8 %mrv_gr
}

---

$ llvm-as < /tmp/a.ll | llc -o /tmp/a.s
Call result #​1 has unhandled type i16
0 llc 0x00770753 _ZN40_GLOBAL__N_Signals.cpp_00000000_8351965815PrintStackTraceEv + 45
1 llc 0x0077094f _ZN40_GLOBAL__N_Signals.cpp_00000000_8351965813SignalHandlerEi + 323
2 libSystem.B.dylib 0x930bd97b _sigtramp + 43
3 ??? 0xffffffff 0x0 + 4294967295
4 libSystem.B.dylib 0x93136782 raise + 26
5 libSystem.B.dylib 0x93145d3f abort + 73
6 llc 0x003d5f71 _ZN4llvm7CCState17AnalyzeCallResultEPNS_6SDNodeEPFbjjjNS_11CCValAssign7LocInfoENS_3ISD10ArgFlagsTyERS0_E + 271
7 llc 0x00292492 _ZN4llvm17X86TargetLowering15LowerCallResultENS_9SDOperandES1_PNS_6SDNodeEjRNS_12SelectionDAGE + 164
8 llc 0x002a7947 _ZN4llvm17X86TargetLowering9LowerCALLENS_9SDOperandERNS_12SelectionDAGE + 12413
9 llc 0x002ae25a _ZN4llvm17X86TargetLowering14LowerOperationENS_9SDOperandERNS_12SelectionDAGE + 2968
10 llc 0x0041b80b ZNSt6vectorIN4llvm9SDOperandESaIS1_EEC1EmRKS1_RKS2 + 67669
11 llc 0x0046385b ZNSt6vectorIN4llvm9SDOperandESaIS1_EEC1EmRKS1_RKS2 + 362661
12 llc 0x00463d5b ZNSt6vectorIN4llvm9SDOperandESaIS1_EEC1EmRKS1_RKS2 + 363941
13 llc 0x00463ef8 _ZN4llvm12SelectionDAG8LegalizeEv + 80
14 llc 0x004acf31 _ZN4llvm16SelectionDAGISel17CodeGenAndEmitDAGERNS_12SelectionDAGE + 257
15 llc 0x004ce412 _ZN4llvm16SelectionDAGISel16SelectBasicBlockEPNS_10BasicBlockERNS_15MachineFunctionERNS_20FunctionLoweringInfoE + 196
16 llc 0x004cff7b _ZN4llvm16SelectionDAGISel13runOnFunctionERNS_8FunctionE + 537
17 llc 0x002cb44f _ZN4llvm17X86TargetLoweringD1Ev + 103
18 llc 0x006fc771 _ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE + 331
19 llc 0x006fc9ca _ZN4llvm23FunctionPassManagerImpl3runERNS_8FunctionE + 110
20 llc 0x006fcb48 _ZN4llvm19FunctionPassManager3runERNS_8FunctionE + 156
21 llc 0x000031da main + 2586
22 llc 0x00002036 start + 54
Abort trap

[llvmbot]

I think this is the issue:

// Scalar values are returned in AX first, then DX.
CCIfType<[i8] , CCAssignToReg<[AL]>>,
CCIfType<[i16], CCAssignToReg<[AX]>>,

so it's trying to return both pieces in AX. What's right here, [AL, DL] perhaps?

[sunfishcode]

The multiple-return-value support in codegen doesn't currently
support returning more values than available registers in the calling
convention.

In this tescase, the i8 value is returned in %al and then the i16
value can't be returned because there are no free integer
registers available in the calling convention.

[sunfishcode]

With this struct in C, it looks like the two result values
are packed into %eax together. So perhaps llvm-gcc
should lower this to a single i32 return value.

[lattner]

I think it should be lowered into AL/DL. We already have a way to return things in AX/EAX, and the front-end can lower to a single i16/i32 when it needs it.

[lattner]

However, there is a bigger issue here. Right now we don't support arbitrary mrv's. Devang, for now, we're just aiming to support the cases that x86-64 needs to get its ABI right, we're not supporting anything that could possible be generated by your optimization pass.

[llvmbot]

This is a valid LLVM IR and it should work. So, I'll keep this PR open.

As per discussion with Evan, I'm directly representing struct return types in IR and let code gen find the right set of registers.

Is it too much work to fix code gen here ?

[lattner]

I agree this should work at some point, but this is much lower prio than getting x86-64 abi right and other short term stuff.

[sunfishcode]

The original testcase is now fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080407/060880.html

However, handling of arbitrary multiple return values remains
a missing feature.

[sunfishcode]

Support for arbitrary return types is being tracked
with llvm/llvm-bugzilla-archive#2660 .

*** This bug has been marked as a duplicate of bug llvm/llvm-bugzilla-archive#2660 ***

[sunfishcode]

mentioned in issue llvm/llvm-bugzilla-archive#2660