> -----Original Message----- > From: sidneym@codeaurora.org > Sent: Friday, July 24, 2020 12:50 PM > To: 'Szabolcs Nagy' > Cc: 'Rich Felker' ; 'musl@lists.openwall.com' > > Subject: RE: [musl] Hexagon DSP support > > > > > -----Original Message----- > > From: Szabolcs Nagy > > Sent: Thursday, July 23, 2020 4:56 PM > > To: sidneym@codeaurora.org > > Cc: 'Rich Felker' ; musl@lists.openwall.com > > Subject: Re: [musl] Hexagon DSP support > > > > * sidneym@codeaurora.org [2020-07-20 > > 16:26:58 -0500]: > > > I removed fma/fmal/fmax/fmin/fabs from compiler-rt-builtins, > > > https://reviews.llvm.org/D82263 > > > The comparison with musl can be found here: > > > https://github.com/quic/musl/compare/hexagon but I've also attached > > > the patch. > > > > > > An assert in clang when building both musl and libc-test for hexagon > > > was fixed by, https://reviews.llvm.org/D80952 prior to this change > > > -frounding-math had to be used. > > > > > > The test-results are also attached. Everything is built with the > > > tip-of-tree llvm so sometimes results vary but these are the results > > > I got from this morning's clone. The only notable difference in the > > > results would be that both fma and fmal fail and this is because of > > > the compiler-rt change. I didn't add fma to musl because it require > > > more complex assembly, along the lines you saw in an earlier version > > > with > > sqrt. > > > > > > the fma and sqrt failures are still not fully explained, e.g. this looks wrong: > > > > src/math/special/fma.h:42: RN fma(0x1p+0,0x1p+0,-0x1p-1074) want > > 0x1p+0 got -0x1.fffffp-43 ulperr -4503599627370496.000 = -0x1p+52 + > > 0x0p+0 > > > > the only target specific bit in fma is a_clz_64 so i would check that. > > > > e.g. a_clz_64(1ULL << 42) should give 21 (this computation happens > > during the fma test case above). > > Hexagon didn't have a_clz_64 implemented however I added this morning it > and noticed no differences. I will update the patch with that routine > included. > > I did notice a compiler regression in how it compiled fma and have asked a > compiler person to take a look. An older version of our internally maintained > compiler does produce the expected results for the values I used but later > versions do not. Unfortunately changing optimization levels will produce > different results as well. I've attached updated test results and patch. The patch doesn't change much other than adding the above mentioned a_clz_64. The only other change was an update to pthread_arch.h for an api update so hexagon conforms with the rest of musl. Between updates to llvm and musl both fma and sqrt issues are resolved provided I compile the library without optimization enabled. No new tests fail. I guess I also need to know what the thoughts are about adding hexagon to the mainline base. There are no issues adding from this end. Thanks,