[libc-commits] [PATCH] D124495: [libc] Implement double precision FMA for targets without FMA instructions.

[Siva Chandra via Phabricator via libc-commits]

sivachandra added inline comments.


================
Comment at: libc/test/src/math/fma_no_fma_test.cpp:10
+#include "src/__support/architectures.h"
+#ifdef LIBC_TARGET_HAS_FMA
+#undef LIBC_TARGET_HAS_FMA
----------------
lntue wrote:
> sivachandra wrote:
> > You should be able to include `generic/FMA.h` directly and avoid this?
> The main point was to test that `__llvm_libc::fma` implementation works correctly without `LIBC_TARGET_HAS_FMA`.  Unfortunately `src.math.fma` is an object target built with just 1 config (FMA flag on our machine) so I choose to inlining its implementation here, which is simply calling `__llvm_libc::fputil::fma`, regardless of FMA flags.  If we include `generic/FMA.h` directly, we wouldn't know/test directly if the `fma` implementation in `generic/FMA.h` is called or `__llvm_libc::fputil::fma` works correctly without FMA flag, unless we run it on non-FMA machines.
> 
> I guess we could instrument the build system to do these, but I'm not sure if it could be cleaner, especially when the behaviors of such functions with or without FMA diverge.
I think this config problem is now widespread enough that we don't want to set precedents like this. I agree that the plumbing from `fputil/FMA.h` to generic of specific implementations will not be tested if you directly use `generic/FMA.h`. But, I think testing your integer implementation should be of primary concern for this patch. We will solve the config problem separately.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124495/new/

https://reviews.llvm.org/D124495