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

[Joshua Cranmer 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);
----------------
jcranmer-intel wrote:

> It seems a bit confusing to rely on host numerics in a function which goes from APFloat -> APFloat. I would recommend that APFloat just have its own copy of the implementation, that way the result of the computation won't depend on the host's ambient conditions.

I'm somewhat concerned about this too. But I've already manually verified that the proposed tests for this method will fail if DAZ/FTZ are enabled, and given that the current state of affairs is that we just blindly call host `exp` or similar for constant folding, this is at least a strict improvement over the current state of affairs

Personally, I'd think it best if the implementation just worked off of `APFloat` values directly, which it likely will have to for `ppc_fp128`, `x86_fp80`, and `fp128` types anyways.

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