[llvm-commits] [llvm] r67502 - /llvm/trunk/lib/Target/X86/X86CallingConv.td

[Frits van Bommel]

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)