[Mlir-commits] [mlir] [mlir][math] Add opt-in f64 round expansion (PR #230408)

Mon Oct 12 23:27:40 PDT 2026

sriramshastry wrote:

> **[krzysz00](/krzysz00) ** left a comment

<html>
<body>
<p style="margin: 0px 0px 16px; color: rgb(191, 191, 191); font-family: "Segoe WPC", "Segoe UI", sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">Thanks for trusting the correctness work. The PR adds IR tests for the f64 expansion and tests confirming that direct MathToLLVM lowering remains unchanged.</p><p style="margin: 0px 0px 16px; color: rgb(191, 191, 191); font-family: "Segoe WPC", "Segoe UI", sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">I don’t know of a target that LLVM cannot handle for f64 rounding, and this patch is not addressing missing LLVM support. I added the option to<span> </span><code style="font-family: Consolas, "Courier New", monospace; font-size: 10.998px; color: rgb(140, 140, 140); background-color: rgb(38, 38, 38); padding: 2px 4px; border-radius: 4px; border: 3px rgb(140, 140, 140); white-space: pre-wrap;">math-expand-ops</code><span> </span>because that pass already expands f32<span> </span><code style="font-family: Consolas, "Courier New", monospace; font-size: 10.998px; color: rgb(140, 140, 140); background-color: rgb(38, 38, 38); padding: 2px 4px; border-radius: 4px; border: 3px rgb(140, 140, 140); white-space: pre-wrap;">math.round</code>; this extends the same arithmetic-expansion capability to f64 for pipelines that want that representation before LLVM lowering.</p><p style="margin: 0px 0px 16px; color: rgb(191, 191, 191); font-family: "Segoe WPC", "Segoe UI", sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">The performance motivation was to investigate whether this expansion could avoid a runtime call. In my local<span> </span><code style="font-family: Consolas, "Courier New", monospace; font-size: 10.998px; color: rgb(140, 140, 140); background-color: rgb(38, 38, 38); padding: 2px 4px; border-radius: 4px; border: 3px rgb(140, 140, 140); white-space: pre-wrap;">-O2</code><span> </span>microbenchmarks, direct lowering of scalar f64<span> </span><code style="font-family: Consolas, "Courier New", monospace; font-size: 10.998px; color: rgb(140, 140, 140); background-color: rgb(38, 38, 38); padding: 2px 4px; border-radius: 4px; border: 3px rgb(140, 140, 140); white-space: pre-wrap;">math.round</code><span> </span>emitted a call to<span> </span><code style="font-family: Consolas, "Courier New", monospace; font-size: 10.998px; color: rgb(140, 140, 140); background-color: rgb(38, 38, 38); padding: 2px 4px; border-radius: 4px; border: 3px rgb(140, 140, 140); white-space: pre-wrap;">round at plt</code><span> </span>with generic x86-64 code generation. The expansion improved the measured scalar and<span> </span><code style="font-family: Consolas, "Courier New", monospace; font-size: 10.998px; color: rgb(140, 140, 140); background-color: rgb(38, 38, 38); padding: 2px 4px; border-radius: 4px; border: 3px rgb(140, 140, 140); white-space: pre-wrap;">v2f64</code><span> </span>cases in that configuration. With Alder Lake-specific code generation, it was substantially slower, so I made the option opt-in and disabled by default.</p><p style="margin: 0px 0px 16px; color: rgb(191, 191, 191); font-family: "Segoe WPC", "Segoe UI", sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">These measurements were taken under on one Intel Core Ultra 9 275HX, comparing generic x86-64 and Alder Lake-specific code-generation configurations on the same host. Each case had 45 paired observations. The percentages below are time reduction versus direct lowering, with uniform/mixed inputs in that order; negative values mean the expansion was slower.</p><div class="monaco-scrollable-element rendered-markdown-table-scroll-wrapper" role="presentation" style="width: 887px; margin-bottom: 16px; color: rgb(191, 191, 191); font-family: "Segoe WPC", "Segoe UI", sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; position: relative; overflow: hidden;"><div style="overflow: hidden;">

```
|Code-generation configuration	|Scalar f64				|v2f64              |
+-------------------------------+-----------------------+-------------------+
|Generic x86-64					|+7.50% / +44.65%		|+16.71% / +47.38%  |
|Alder Lake-specific			|-499.12% / -503.65%	|-245.93% / -246.70%|

```

</div><div role="presentation" aria-hidden="true" class="invisible scrollbar horizontal" style="opacity: 0; pointer-events: none; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0); position: absolute; width: 887px; height: 8px; left: 0px; bottom: 0px;"><div class="slider" style="background: none 0% 0% / auto repeat scroll padding-box border-box rgba(168, 169, 170, 0.52); border-radius: 4px; position: absolute; top: 0px; left: 0px; height: 8px; transform: translate3d(0px, 0px, 0px); contain: strict; width: 887px;"></div></div><div role="presentation" aria-hidden="true" class="invisible scrollbar vertical" style="opacity: 0; pointer-events: none; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0); z-index: 14; position: absolute; width: 0px; height: 89px; right: 0px; top: 0px;"><div class="slider" style="background: none 0% 0% / auto repeat scroll padding-box border-box rgba(168, 169, 170, 0.52); border-radius: 4px; position: absolute; top: 0px; left: 0px; width: 8px; transform: translate3d(0px, 0px, 0px); contain: strict; height: 89px;"></div></div></div><p style="margin: 0px 0px 16px; color: rgb(191, 191, 191); font-family: "Segoe WPC", "Segoe UI", sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">These are microbenchmark results, not application-level gains, and they do not show that the expansion is universally faster or that LLVM lacks f64 support. I don’t currently have a concrete downstream consumer requiring this representation. Is extending the existing pass with this opt-in capability sufficient rationale, or would you prefer a demonstrated consumer?</p>
</body>
</html>

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