[libc-commits] [libc] [llvm] [libc] Make totalorder functions use the emulated float128 type (PR #221085)

[Muhammad Haris Awan via libc-commits]

harisawan-bit wrote:

Thanks for the review — headers are done. Pushed `9f87754` to this branch, rewriting all 10 touched files to the standard one-line banner (verified byte-identical to the same files on `main`). The remaining `\file` Doxygen blocks were dropped to match `libc/src/math/totalorderf128.h`, `libc/src/math/generic/totalorderf128.cpp` and `libc/test/src/math/smoke/totalorderf128_test.cpp` as they exist upstream.

On the MPFR tests: I dug into the wrapper before replying, and I don't think an MPFR-based test is implementable for `totalorder` as the harness currently stands:

- `LIBC_NAMESPACE::testing::mpfr::Operation` (`libc/utils/MPFRWrapper/MPFRUtils.h`) only models operations that *produce a floating-point value* — unary/binary/ternary, one or two outputs. There is no comparison or total-ordering entry, and `is_valid_operation()` constrains inputs/outputs to floating-point types, so there's no slot for a predicate returning `int`.
- MPFR itself has no `total_order` equivalent exposed here; the ordering has to be derived from the operands' sign/exponent/mantissa, which is exactly what this implementation does.

The good news is float128 *is* supported by the wrapper (`mpfr_set_float128` and `ExtraPrecision<float128>` in `libc/utils/MPFRWrapper/MPCommon.h`), so arithmetic f128 functions can still be MPFR-tested — it's specifically the ordering semantics that don't map.

So for coverage I'd like to extend the existing `TotalOrderTestTemplate` instead, which is the pattern already used by `totalorderf16_test.cpp` and `totalorderbf16_test.cpp` (plain `Sign`/`FPMatcher`, no MPFR). Concretely, on top of the smoke tests this PR already adds:

- `totalorderf128`/`totalordermagf128` for the full sign matrix (`-0.0` vs `+0.0`, which is the case this emulated implementation actually exists to get right)
- NaN payload ordering, including quiet vs signalling NaN
- `+inf`/`-inf` ordering against normal and subnormal values
- subnormal boundaries

Happy to also add a `LIBC_TYPES_HAS_NATIVE_FLOAT128` guard path if you'd like the native-float128 targets covered separately. Would that satisfy the test requirement, or did you have a different MPFR mechanism in mind? Re-requesting your review once you've had a look.


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