[llvm-commits] [llvm] r67502 - /llvm/trunk/lib/Target/X86/X86CallingConv.td
Frits van Bommel
fvbommel at wxs.nl
Mon Mar 23 03:07:19 PDT 2009
Dan Gohman wrote:
> // Return-value conventions common to all X86 CC's.
> def RetCC_X86Common : CallingConv<[
> - // Scalar values are returned in AX first, then DX.
> + // 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
> + // is AH 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]>>,
> CCIfType<[i16], CCAssignToReg<[AX, DX]>>,
> CCIfType<[i32], CCAssignToReg<[EAX, EDX]>>,
Is this "convention" documented anywhere? I looked at the ABI documents
I have (System V i386 abi and the AMD64 abi), and the first makes no
mention that I can find of returning multiple integers in registers
while the second explicitly says the second integer part of a struct,
when returning it in registers, is to be returned in %rdx...
Is there any reason you can't just use DL as the second i8 register?
(even if only for fastcc?)
In my case, packing two i8 values into an i16 isn't a solution since the
first value might be an i16/i32/i64 (on x86-64).
On a related topic, is there any way for a frontend to determine whether
or not the backend will abort() if it tries to generate code for
returning a given struct type in registers? (assuming it has pointers to
the relevant TargetData and TargetMachine)
More information about the llvm-commits
mailing list