[libc-commits] [clang] [libc] [llvm] [clang] Make __builtin_exp and __builtin_expf constexpr. (PR #199808)

[Hubert Tong via libc-commits]

hubert-reinterpretcast wrote:

> My understanding from @AaronBallman is that we're planning to handle this by just using the same C++ `constexpr` machinery for C `constexpr`.

As purely a pragmatic implementation decision where we are just using what we have for C++ anyway, I can understand this decision. At the end of the day though, the C wording treats both cases as parallel. In C2y draft N3886, subclause F.8.5, "Constant Expressions" (an earlier version of which you quote above) has:
> An arithmetic constant expression of floating type, other than one in an initializer for an object that has static or thread storage duration or that is declared with storage-class specifier `constexpr`, is evaluated (as if) during execution; [...]

So I still think we should ideally be doing the same thing for the C `constexpr` case as for the static/thread-storage initialization one; which, based on the rest of your comment means folding cases with "errors" at least for IEEE-like types.

Anyhow, I think we can switch the C `constexpr` behaviour later. It seems we will have both choices of behaviour implemented anyway.

> CFP, in my conversations with them, is pretty equally adamant that under IEEE 754 rules, `1.0/0.0` yielding infinity at translation time is totally the right thing. (I'd have to defer to Rajan for a ruling on behavior on systems like HexFloat without infinity/NaN).

Okay. I'll reach out to Rajan to confirm whether we want the translation to fail in the HexFloat case. As noted in the [HexFloat RFC thread](https://discourse.llvm.org/t/rfc-hexfloat-floating-point-support/75833/48), there is no obvious, consistent result value for error cases. The PR also uses `std::optional` in a way that evaluation of the math function call could return no "value".

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