[PATCH] D11438: Fix x86_64 fp128 calling convention

[Chih-hung Hsieh via llvm-commits]

On Tue, Oct 13, 2015 at 9:21 AM, Quentin Colombet <qcolombet at apple.com>
wrote:

>
> This is interesting observation: fp128 gets split into 2-64-bit registers.
> Looks like we could go incrementally here.
> What about:
> 1. Changing the android ABI to pass the fp128 via xmm registers, but let
> the values live wherever they currently live in the meantime.
> 2. Fixing the AsmPrinter.
> 3. Fixing the split of the value into 2-64bit registers.
>
>
2. is probably the simplest and independent part that can go in before the
others. The change is only in lib/Target/X86/X86MCInstLower.cpp. If it is
left out, llvm can compile libm, but abort on -g in some cases.

1. was what I wanted at the beginning and I don't mind using 2 64-bit
registers in other operations if that is possible.

However, after I made the following changes for calling convention:
   lib/Target/X86/X86RegisterInfo.td
   lib/Target/X86/X86CallingConv.td
   lib/Target/X86/X86InstrInfo.td
I found missing instructions to handle fp128 values load/store in xmm
registers, although there were many to process vectors in xmm.
So we need some extra load/store instructions in
   lib/Target/X86/X86InstrSSE.td
Once f128 is 'legal' in register, it seemed easier for llvm to pass it
around than converting back-and-forth between 128-bit and 2x64-bit
registers.
In fact since almost all f128 operations are handled by library functions,
the values are mostly passed around and in f128 registers.

I didn't try it but I think it would probably require more twist of current
llvm code to keep f128 in 2 64-bit registers and pass in xmm.
Anyway, if anyone knows how to configure llvm easily, we can try that.

Actually most of the changes were required to compile libm, which uses
unions to access floating point bits as integers. We need instructions to
handle i128 vs f128 issues. Hence, the need of only "partial" logic in
LegalizeFloatTypes.cpp.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151013/be199479/attachment.html>