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

[Xinliang David Li via llvm-commits]

that is great!

David

On Fri, Dec 11, 2015 at 6:09 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- 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