[PATCH] D11438: Part 2 to fix x86_64 fp128 calling convention.

Hal Finkel via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 11 18:09:14 PST 2015


----- Original Message -----
> From: "Xinliang David Li via llvm-commits" <llvm-commits at lists.llvm.org>
> To: "Chih-hung Hsieh" <chh at google.com>
> Cc: "llvm-commits" <llvm-commits at lists.llvm.org>, reviews+D11438+public+6e2ebe02f28cebc7 at reviews.llvm.org, "Elliott
> Hughes" <enh at google.com>
> Sent: Friday, December 11, 2015 8:06:11 PM
> Subject: Re: [PATCH] D11438: Part 2 to fix x86_64 fp128 calling convention.
> 
> On Fri, Dec 11, 2015 at 4:41 PM, Chih-hung Hsieh <chh at google.com>
> wrote:
> >>
> >> > ================
> >> > Comment at: test/CodeGen/X86/fp128-i128.ll:44
> >> > @@ +43,3 @@
> >> > +; CHECK:       movaps %xmm0, -24(%rsp)
> >> > +; CHECK-NEXT:  movq -24(%rsp), %rax
> >> > +; CHECK-NEXT:  movabsq $281474976710655, %rcx
> >> > ----------------
> >> > davidxl wrote:
> >> >> The pattern checked is pretty long -- I worry it may break in
> >> >> the
> >> >> future. Is it possible to relax it some how?
> >> > I tried to reduce the C code, but any reduction won't trigger
> >> > the
> >> > complicated IL that reached a point that my partial fix core
> >> > dumped. Maybe
> >> > we can take out a few CHECK-NEXT requirements.
> >>
> >> Where does it core-dump? If it is in new code, it needs to be
> >> fixed :)
> >> Otherwise file a bug.
> >>
> >
> > Ah, I meant my incomplete fix at some time in the past.
> > My current patch passes these tests.
> > Adding these tests might catch future regression if anyone changes
> > f128
> > optimization.
> >
> >
> >>
> >> >
> >> > On the other hard, I was terrified by so many ad-hoc
> >> > optimizations of
> >> > floating points for the usage patterns in libm.
> >> > I guess llvm tried to match or do better then gcc and libm tried
> >> > to use
> >> > every possible bit operations.
> >> > So maybe it is better for Android or anyone depends on f128 type
> >> > to have
> >> > more check rules here.
> >> > Whoever changes float optimization in the future has better
> >> > fully
> >> > understand and update these tests.
> >>
> >> Maybe these complicated/fragile case do not belong here -- but
> >> somewhere downstream (libm).
> >
> >
> > Yes, AOSP bionic has already libm unit tests.
> > Most of my unit tests here are reduced from failed cases I hit with
> > my
> > incomplete work.
> > Now this patch passes all AOSP libm tests.
> >
> > It's difficult to expect all people changing LLVM floating points
> > run
> > through all libm tests for the Android target. So I do my best to
> > add more
> > unit tests here.
> >
> 
> I suggest implementing __float128 in Clang as  follow up

Nemanjai is already working on this (http://reviews.llvm.org/D15120).

 -Hal

> so that
> others can benefit from this feature other than Android.
> 
> David
> 
> > -- chh
> >
> >
> >>
> >>
> >> David
> >>
> >>
> >> >
> >> >
> >> >
> >> >
> >> > http://reviews.llvm.org/D11438
> >> >
> >> >
> >> >
> >
> >
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory


More information about the llvm-commits mailing list