[libc-commits] [libc] [libc][math] Qualify log with constant evaluation support (PR #184745)

[Muhammad Bassiouni via libc-commits]

bassiounix wrote:

So, the rational for `LIBC_CONSTEXPR` is not to replace `constexpr` qualifier completely, but rather:
- to indicate the function may or may not have constant evaluation code
- work hand in hand with `LIBC_ENABLE_CONSTEXPR` to force constant evaluation code in function body
- mark these functions as `constexpr` when the constant evaluation path is forced

Any function that can be `constexpr` all the way with no violation in its function body shall be marked as `constexpr`.
Any function that is needed in constant evaluation context but it has compliant and non-compliant code section in it shall be marked as `LIBC_CONSTEXPR`.

`LIBC_CONSTEXPR` does not mark or qualify the function as `constexpr` if it's not enforced manually.

The constraints it poses is the following:
- Any function that uses `constexpr`-qualified function can be qualified either as `constexpr`, `LIBC_CONSTEXPR` or none.
- Any function that uses `LIBC_CONSTEXPR`-qualified function can only be qualified as `LIBC_CONSTEXPR` (because of the nature of `LIBC_CONSTEXPR`) or none

We can get rid of `LIBC_CONSTEXPR` and only mark as `constexpr` all the way but this will cause trouble with GCC as noted before in the refactoring effort when we are not producing `constexpr` expressions, so that's why we need a way to dynamically adjust the qualifier and the underlying code according to the evaluation mode.

It shall be noted that the constant evaluation code route used to implement internal utils as `constexpr` compatible depends on a specific compiler features that's not available in all compilers/versions, thus the dependent targets (`LLVM::APFloat` in this case) should upgrade the minimum compiler version used to compiler this specific portion of the code.

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