[Know-It-All-Brother]

Part of the Ampere accuracy series (#2040). It depends on #2041 for the test: the commits before this PR's own are #2041's and drop out once it lands, so this PR's own change is the last commit.

What and why

tanh.approx.f32 and tanh.approx.f16x2 compile to MUFU.TANH (MUFU op 9). The translator had no case for it, and its IR had no hyperbolic tangent, so these shaders failed to translate.

This adds a HyperbolicTangent IR instruction (GLSL.std.450 Tanh in SPIR-V) and MUFU op 9:

• The f32 form is precise::tanh. Like the other MUFU functions, it's Metal's approximation against NVIDIA's, so it joins the test's approximations list. Every special value matches the Orin: ±0, subnormals (tanh(x) = x, no flush), ±inf → ±1 and |x| ≥ 8 → ±1. NaN differs only in its bits.
• The f16 form follows what the Orin does, read from its results: it returns x for |x| < 2^-8, ±1 from 8 up, and in between tanh rounded toward zero to half. That model matches all but 3 of 1,876 finite halves, and those 3 are 1 ULP off. It costs 7 integer operations and 2 selects per half on top of the tanh.

Reference entry: "MUFU.TANH" in docs/reference/shaders.md.

#1412 also translates MUFU.TANH, as 1 − 2/(e^{2x}+1). Against the Orin the two are close for f32 (498 lanes off, max 323 ULP for #1412; 496, max 116 here), and for f16 this PR is much closer (3 halves against 632), because the GPU rounds tanh toward zero. I've posted the comparison on #1412 and suggested landing TANH through this PR.

How to verify

DMSH_TEST_XLATE=dm/gfx/tools/dmsh_xlate_bin/dmsh_xlate AMPERE_ORIN_ONLY=mufu_tanh,mufu_tanh_f16x2 python3 dm/gfx/tests/test_dmsh_ampere_orin.py

Op	main	this PR
mufu_tanh (of 1,024)	failed to translate	523 differ: 496 within Metal's approximation (median 1 ULP, max 116) and 27 NaN bit patterns
mufu_tanh_f16x2 (halves of 2,048)	failed to translate	118 differ: 115 NaN bit patterns, 3 at 1 ULP (632 with a plain round-to-nearest pack)

Both move from KNOWN to APPROX. The f16 thresholds (2^-8 and 8) are inferred from the fixture's samples and aren't proven bit for bit. The GPU's f32 form also returns x for |x| < 2^-8; copying that would take 3 more operations, which I haven't done.

Checked

• Tests: test_dmsh_ampere_orin.py; every other test_dmsh_* gives the same result as on main (test_dmsh_ampere_mem.py, test_dmsh_meshstage.py and test_dmsh_pairs.py fail on main the same way); test_nsp_chain.py, test_xlate_anycpu.py, test_docs.py. lint_python.py shows no new findings.
• Translator: the dlls are rebuilt from this tree with .NET 10; tool_lock.py --update-lock and dmsh_chain.py --header were run (chain c87293dfe3d3).
• Devices and OS: MacBook Pro M5 Max, macOS 27.
• regress.py: not run. My only local Switch 2 build's shader package comes from an older shader split than main's map, so main's chain can't build it. Ocarina of Time's build already translates every shader, so it can't contain this instruction.
• Games run: none.

Docs

• docs/reference/shaders.md has the entry, and python3 dm/tools/docs_symptoms.py was run
• A chain tool changed: dmsh_chain.py --header was run, and dmsh_chain.h, the translator dlls and the lock are part of the change
• No game files, keys or data extracted from a game