<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 13, 2015 at 9:21 AM, Quentin Colombet <span dir="ltr"><<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
</span>This is interesting observation: fp128 gets split into 2-64-bit registers.<br>
Looks like we could go incrementally here.<br>
What about:<br>
1. Changing the android ABI to pass the fp128 via xmm registers, but let the values live wherever they currently live in the meantime.<br>
2. Fixing the AsmPrinter.<br>
3. Fixing the split of the value into 2-64bit registers.<br><div class=""><div class="h5"><br></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>However, after I made the following changes for calling convention:</div><div><div>   lib/Target/X86/X86RegisterInfo.td</div><div>   lib/Target/X86/X86CallingConv.td</div><div>   lib/Target/X86/X86InstrInfo.td</div></div><div>I found missing instructions to handle fp128 values load/store in xmm registers, although there were many to process vectors in xmm.</div><div>So we need some extra load/store instructions in</div><div>   lib/Target/X86/X86InstrSSE.td</div><div>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.</div><div><div>In fact since almost all f128 operations are handled by library functions, the values are mostly passed around and in f128 registers.</div></div><div><br></div><div>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.</div><div>Anyway, if anyone knows how to configure llvm easily, we can try that.</div><div><br></div><div>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.</div><div><br></div></div></div></div>