Chih-hung Hsieh
2015-Jul-13 19:33 UTC
[LLVMdev] __float128 (f128) calling convention bug on x86_64
Hello, I'm new to this mailing list and fixing llvm bugs for Android. Can anyone point me to any previous discussion or work related to the following bug? https://llvm.org/bugs/show_bug.cgi?id=23897 I am testing my patch to llvm to make f128 values stay in SSE registers instead of being split into two i64 values. I have tried to add a register class FR128 to hold f128 values for the x86_64 target. Preliminary tests seem to be working and compatible with gcc's __float128 long double type. I found that long double complex (with two f128 values) also have calling convention compatibility problem with gcc and can be fixed similarly. My current patch does change quite a few places in type legalizing pass and some other optimizations related to f128 or i128 values. A few changes in the softening of floating point types to keep some f128 typed IR and convert some f128 opcode to library function calls. Has anyone tried this approach or have other solution? Thanks -- Chih-Hung -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150713/b39948d1/attachment.html>
Reid Kleckner
2015-Jul-15 16:01 UTC
[LLVMdev] __float128 (f128) calling convention bug on x86_64
On Mon, Jul 13, 2015 at 12:33 PM, Chih-hung Hsieh <chh at google.com> wrote:> > I found that long double complex (with two f128 values) also have calling > convention compatibility problem with gcc and can be fixed similarly. > My current patch does change quite a few places in type legalizing pass > and some other optimizations related to f128 or i128 values. A few changes > in the softening of floating point types to keep some f128 typed IR and > convert some f128 opcode to library function calls. > > Has anyone tried this approach or have other solution? >It sounds like you're on the right track for the low-level part of this. The responsibility of matching platform ABI calling conventions is sort of split across clang and LLVM. I think the way to get the calling convention right is to change Clang to use x86_fp80 as the LLVM type for parameter and return types, with some extra coercions inserted before calls and in function prologues. The mangling will need a separate change as it doesn't look at LLVM IR. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150715/b23aed66/attachment.html>
David Majnemer
2015-Jul-15 16:42 UTC
[LLVMdev] __float128 (f128) calling convention bug on x86_64
On Wed, Jul 15, 2015 at 9:01 AM, Reid Kleckner <rnk at google.com> wrote:> On Mon, Jul 13, 2015 at 12:33 PM, Chih-hung Hsieh <chh at google.com> wrote: >> >> I found that long double complex (with two f128 values) also have calling >> convention compatibility problem with gcc and can be fixed similarly. >> My current patch does change quite a few places in type legalizing pass >> and some other optimizations related to f128 or i128 values. A few changes >> in the softening of floating point types to keep some f128 typed IR and >> convert some f128 opcode to library function calls. >> >> Has anyone tried this approach or have other solution? >> > > It sounds like you're on the right track for the low-level part of this. > > The responsibility of matching platform ABI calling conventions is sort of > split across clang and LLVM. I think the way to get the calling convention > right is to change Clang to use x86_fp80 as the LLVM type for parameter and > return types, with some extra coercions inserted before calls and in > function prologues. > > The mangling will need a separate change as it doesn't look at LLVM IR. >I think you'll want to implement "useFloat128ManglingForLongDouble" for the mangling change.> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150715/d410d9ec/attachment.html>