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

Chih-hung Hsieh via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 11 16:41:33 PST 2015


>
>
> > ================
> > 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.

-- chh



>
> David
>
>
> >
> >
> >
> >
> > http://reviews.llvm.org/D11438
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151211/8bf0e228/attachment.html>


More information about the llvm-commits mailing list