[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 19 Jun 2020 16:58:53 -0500
From: <sidneym@...eaurora.org>
To: "'Szabolcs Nagy'" <nsz@...t70.net>
Cc: <musl@...ts.openwall.com>
Subject: RE: Hexagon DSP support
> -----Original Message-----
> From: Szabolcs Nagy <nsz@...t70.net>
> Sent: Thursday, June 18, 2020 4:43 PM
> To: sidneym@...eaurora.org
> Cc: musl@...ts.openwall.com
> Subject: Re: [musl] Hexagon DSP support
>
> * sidneym@...eaurora.org <sidneym@...eaurora.org> [2020-06-18 11:37:05
> -0500]:
> > I attached the updated REPORT with warning output disabled, -w and
> > -fno-rounding-math (See https://bugs.llvm.org/show_bug.cgi?id=45329)
> > along with the patch. I've rebased a couple of times without any
> > conflicts and the git repo is here:
> > https://github.com/quic/musl/tree/hexagon
>
> the fmal failures are a bit concerning:
>
> fmal should be a tail call to fma if long double has the same
representation as
> double. (can you please verify this? there should be a single branch
instruction
> in fmal)
>
> there are no fma failures with the same tests so fmal should work fine
too.
In the case of fma the selected function comes from compiler-rt-builtins.
It looks like since fmal calls fma within the context of the c-library the
c-library's version is branched to.
compiler-rt-builtins for hexagon should include a fmal function that jumps
to the optimized fma, it does not but I can fix that.
I generally only use the tip-of-tree clang and that isn't generating correct
code when building fma.c. When I use our internally release llvm tools fma
and fmal tests both pass.
Thanks
>
> may be the libc-test code got miscompiled or somehow wrong?
> or long double arithmetics is broken?
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
