[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