[llvm] [APFloat] Add exp function for APFloat::IEEESsingle using expf implementation from LLVM libc. (PR #143959)

[via llvm-commits]

================
@@ -5601,6 +5606,35 @@ float APFloat::convertToFloat() const {
   return Temp.getIEEE().convertToFloat();
 }
 
+#ifdef LLVM_INTEGRATE_LIBC
+APFloat exp(const APFloat &X, RoundingMode rounding_mode) {
+  assert((&X.getSemantics() == (const llvm::fltSemantics *)&semIEEEsingle) &&
+         "Float semantics is not IEEEsingle");
+  if (&X.getSemantics() == (const llvm::fltSemantics *)&semIEEEsingle) {
+    int current_rounding_mode = fegetround();
+    switch (rounding_mode) {
+    case APFloat::rmNearestTiesToEven:
+      fesetround(FE_TONEAREST);
----------------
lntue wrote:

The main problem the preventing linking LLVM libc directly to LLVM / APFloat is that ideally, the libc project belongs to the `LLVM_ENABLE_RUNTIMES` list which will be built after LLVM and clang in the `LLVM_ENABLE_PROJECTS` list.  To break that build dependency cycle, and simplify build systems for both projects, I think letting LLVM directly include and build libc's math functions is the simplest way.

On the other hand, I do see 2 problems that might arise: 
- we might need to build these libc math routines wrapped inside `#pragma STDC FENV_ACCESS ON` to make sure that the floating point environment accesses are not shuffled around.  At the moment it looks like they are built correctly, but it would be safer to put them under the pragma.
- as more and more math routines are included directly, it might be slow to build `APFloat.cpp`, so we might need to refactor them into separate TUs to speed up the build.

What do you think about refactor this into something like `APFloatMath.cpp` or `APFloatExpLog.cpp`, put them under `#pragma STDC FENV_ACCESS ON`, and then add them to `LLVMSupport`?

https://github.com/llvm/llvm-project/pull/143959