Richard Henderson <richard.hender...@linaro.org> writes:
> On 9/17/19 5:00 PM, Alex Bennée wrote: >>>> + add_f32_const(0x8p-152); >>>> + add_f32_const(0x8p-152); >>>> + add_f32_const(0x8p-152); >>> >>> Why are you adding 3 of the same? >> >> To replicate the 1841491 test case where the same number is used for >> a/b/c > > Then we really ought to be more explicit about that. I guess - I was hoping to piggy back on the general case. Maybe we should just split that into a separate test case. We can at least re-use the format and flag printing code and drop the behind the scenes magic to "join" the constant table with extra test values. > You're not doing full permutations on the sets of numbers, so does > incrementing > a random index really test what you intended? I did initially do the full permutation but for madds it all adds up quite quickly. The shuffle we do here is a bit of a comprise, so it shuffles the various nan forms before nans with -inf and -large and finally a bunch of real numbers (subnormals in the middle). It gives a reasonably broad coverage without going nuts. > >>>> +#if defined(__arm__) >>>> + r = __builtin_fmaf(a, b, c); >>>> +#else >>>> + r = __builtin_fmaf(a, b, c); >>>> +#endif >>> >>> Eh? >> >> Ahh I was going to hardcode the arm madd instruction in as the builtin >> wasn't expanding. I tried setting -march in the CFLAGS but that didn't >> trigger it either on my buster arm-hf compiler. Any ideas how to get the >> compiler to do the right thing? > > I think you want -mfpu=neon-vfpv4. Ahh that worked. I would have hoped that v8 would be enough to spit out aarch32 code which has to have VFPv4 for A profile right? Anyway I'll use that for now. > > > r~ -- Alex Bennée
