I was convinced that it's ok to allow a second i8 return value

to be returned in DL. LLVM's multiple-return-value support is
not ABI-conforming; front-ends that wish to have code emitted
that conforms to an ABI are currently expected to make
arrangements for this on their own rather than assuming that
multiple-return-values will automatically do the right thing.
This commit doesn't fundamentally change this situation.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@67588 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Dan Gohman 2009-03-24 01:04:34 +00:00
parent 8f4aa333d0
commit a96dc14968

View File

@ -22,13 +22,14 @@ class CCIfSubtarget<string F, CCAction A>
// Return-value conventions common to all X86 CC's.
def RetCC_X86Common : CallingConv<[
// Scalar values are returned in AX first, then DX, except for i8 where
// the convention is to return values in AL and AH. However, using AL and
// AH is problematic -- a return of {i16,i8} would end up using AX and AH,
// and one value would clobber the other. C front-ends are currently expected
// to pack two i8 values into an i16 in the rare situations where this
// is necessary.
CCIfType<[i8] , CCAssignToReg<[AL]>>,
// Scalar values are returned in AX first, then DX. For i8, the ABI
// requires the values to be in AL and AH, however this code uses AL and DL
// instead. This is because using AH for the second register conflicts with
// the way LLVM does multiple return values -- a return of {i16,i8} would end
// up in AX and AH, which overlap. Front-ends wishing to conform to the ABI
// for functions that return two i8 values are currently expected to pack the
// values into an i16 (which uses AX, and thus AL:AH).
CCIfType<[i8] , CCAssignToReg<[AL, DL]>>,
CCIfType<[i16], CCAssignToReg<[AX, DX]>>,
CCIfType<[i32], CCAssignToReg<[EAX, EDX]>>,
CCIfType<[i64], CCAssignToReg<[RAX, RDX]>>,