|
Message-ID: <096001d64684$d322d0f0$796872d0$@codeaurora.org> 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.