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

[Aaron Ballman via llvm-commits]

================
@@ -5601,6 +5604,29 @@ float APFloat::convertToFloat() const {
   return Temp.getIEEE().convertToFloat();
 }
 
+static constexpr int getFEnvRoundingMode(llvm::RoundingMode rm) {
+  switch (rm) {
+  case APFloat::rmTowardPositive:
+    return FE_UPWARD;
+  case APFloat::rmTowardNegative:
+    return FE_DOWNWARD;
+  case APFloat::rmTowardZero:
+    return FE_TOWARDZERO;
+  default:
+    // TODO: fix rmNearestTiesToAway for platform without FE_TONEARESTFROMZERO.
+    return FE_TONEAREST;
+  };
+}
+
+APFloat exp(const APFloat &X, RoundingMode rounding_mode) {
+  if (&X.getSemantics() == &semIEEEsingle) {
+    float result = LIBC_NAMESPACE::shared::expf(
+        X.convertToFloat(), getFEnvRoundingMode(rounding_mode));
+    return APFloat(result);
----------------
AaronBallman wrote:

I spoke with @lntue about this offline and he convinced me that a design where llvm-libc is at the lowest library layer is actually reasonable. The chances of llvm libc being able to use LLVM's ADT library are pretty small, and the amount of effort required to factor ADT out into "freestanding" bits would be significant. That said, we have to be careful to ensure conversions between `APFloat` and the internal representation for llvm-libc are lossless for all targets and inexpensive (so we don't have too much overhead when constant evaluating C++ code, for example).

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