Problem
The Metal frontend currently maps metal::precise::acos to the shared acos intrinsic without retaining the source precision mode. On Direct3D 12 WARP, the resulting HLSL intrinsic can exceed the source workload's float32 numerical contract even though the shader compiles and executes successfully.
This affects any Metal repository that relies on the precise math namespace. It was reproduced while translating the pinned MLX v_ArcCosfloat32float32 entry from commit 846d176227a0ac13d2667e58d2bb68b322109ab0: three of five representative values exceeded MLX's inverse-trigonometric tolerance, with a maximum absolute error of approximately 6.75e-5.
Required behavior
- Retain the distinction between default, fast, and precise Metal math calls through reverse code generation.
- Lower
metal::precise::acos to a portable implementation whose float32 error satisfies the source contract across [-1, 1], including endpoints and invalid-domain behavior.
- Keep target output independently compilable; do not rely on runtime-specific source rewriting.
- Preserve ordinary
metal::acos, metal::fast::acos, and unqualified user overload behavior.
- Support scalar float calls and define an explicit policy for vector calls.
Acceptance criteria
- Focused Metal frontend tests verify that precise and default calls remain distinct.
- DirectX and OpenGL codegen tests compile the emitted helper and cover representative values across the domain.
- The pinned MLX ArcCos entry compiles and executes through the native Direct3D 12 and OpenGL loaders within MLX's float32 inverse-trig tolerance.
- Unsupported precise signatures fail with a structured diagnostic instead of silently falling back to a lower-accuracy intrinsic.
Current evidence
The selected MLX entry and generated artifact are otherwise correct: the float overload is selected, the complex out-of-line overload is pruned, DXC accepts the HLSL, and the Direct3D loader returns five float32 values. The remaining mismatch is isolated to loss of the source precision contract.
Problem
The Metal frontend currently maps
metal::precise::acosto the sharedacosintrinsic without retaining the source precision mode. On Direct3D 12 WARP, the resulting HLSL intrinsic can exceed the source workload's float32 numerical contract even though the shader compiles and executes successfully.This affects any Metal repository that relies on the precise math namespace. It was reproduced while translating the pinned MLX
v_ArcCosfloat32float32entry from commit846d176227a0ac13d2667e58d2bb68b322109ab0: three of five representative values exceeded MLX's inverse-trigonometric tolerance, with a maximum absolute error of approximately6.75e-5.Required behavior
metal::precise::acosto a portable implementation whose float32 error satisfies the source contract across[-1, 1], including endpoints and invalid-domain behavior.metal::acos,metal::fast::acos, and unqualified user overload behavior.Acceptance criteria
Current evidence
The selected MLX entry and generated artifact are otherwise correct: the float overload is selected, the complex out-of-line overload is pruned, DXC accepts the HLSL, and the Direct3D loader returns five float32 values. The remaining mismatch is isolated to loss of the source precision contract.