The current generic implementation of the fmaf function has been moved
to the FPUtil directory. This allows one use the fma operation from
implementations of other math functions like the trignometric functions
without depending on/requiring the fma/fmaf/fmal function targets. If
this pattern ends being convenient, we will switch all generic math
implementations to this pattern.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I have not yet fully tested this patch on x86_64. Will update soon if it requires any changes.
libc/utils/FPUtil/FMA.h | ||
---|---|---|
15 | Do we also need to check for _ _FMA__ flag? |
Stupid question: why assembler instead of builtins:
https://github.com/gcc-mirror/gcc/blob/master/gcc/testsuite/gcc.target/ia64/builtin-fma-1.c
I guess there is a tradeoff between control over the process and helping the register allocator.
Builtins can potentially silently call into the libc. I preferred inline assembly to avoid such a possibility. I think using target specific compiler intrinsics is a better option but they don't have convenient ways to convert from intrinsic types like __m128 to and from float/double.
libc/utils/FPUtil/FMA.h | ||
---|---|---|
15 | I agree that not checking on __FMA__ is not ideal. But, I preferred not to condition on any other thing because it complicates the build system. For example, if __FMA__ was not defined, then we wouldn't get the hardware fma and fmaf but only get the integer fmaf implementation. But, other places will expect that fma and fmaf both are available. We can of course teach the build system to check for __FMA__ and propagate that info suitably to the rest of the libc build. That is a change we can take up separately if really required. I would prefer to see more examples of that pattern before building the appropriate machinery in to the build system. |
Do we also need to check for _ _FMA__ flag?