[llvm] [X86] Use round-to-odd for f64->f16 with F16C (PR #230079)
Aochang Liu via llvm-commits
llvm-commits at lists.llvm.org
Sun Oct 11 22:46:56 PDT 2026
HelloWorldU wrote:
Based on the above discussion, I measured it on an i7-9750H (Coffee Lake). Each loop does scalar conversions only; the libcall is compiler-rt's `__truncdfhf2` built with clang -O2. Numbers are ns per conversion, best of 7 runs:
| | libcall | round-to-odd | two-step (`vcvtsd2ss` + `vcvtps2ph`) |
| --- | --- | --- | --- |
| throughput, inputs in f16 normal range | 5.3 | 2.3 | 0.75 |
| throughput, mixed inputs (subnormal, normal, overflow) | 7.3 | 2.3 | 0.74 |
| latency, inputs in f16 normal range | 9.0 | 9.1 | 5.5 |
| latency, mixed inputs | 10.6 | 9.1 | 5.4 |
Code size per conversion: 8 bytes for the libcall, about 70 bytes plus a 16-byte constant for round-to-odd.
What each approach generates (throughput, normal-range inputs):
| | hook | round-to-odd |
| --- | --- | --- |
| `fptrunc double to half` | libcall (5.3) | round-to-odd (2.3) |
| contract two-step | two-step (0.75) | round-to-odd (2.3) |
So round-to-odd has 2-3x the throughput of the libcall, about the same latency, and much larger code. The hook keeps the contract two-step case fastest but leaves the plain case as a libcall.
CC @RKSimon @Andarwinux.
https://github.com/llvm/llvm-project/pull/230079
More information about the llvm-commits
mailing list