fix: unblock the Xtensa f32 builtins build (LLVM constant-pool workaround)

[Yona-Appletree]

Stacked on #241 (claude/f32-m7-p1p2-vinst-lowering) — it carries the M7
P1/P2 wiring this needs. Merges onto/after #241; retarget to main once #241
lands. Note that a PR based on a claude/* branch matches no CI trigger, so
the suite runs on retarget (this is documented in pre-merge.yml).

What was blocked

LP_XT_BUILTINS_F32=1 ./scripts/build-builtins-xt.sh failed in the backend:

rustc-LLVM ERROR: Cannot select: i32 = XtensaISD::PCREL_WRAPPER
  TargetConstantPool:i32<@.LCP162_3 = internal constant [2 x float]
  [float 0.000000e+00, float -1.000000e+00]> 0
In function: __lp_lpfn_rgb2hsv_f32

That build now succeeds. The gate flip does not, for a reason nobody knew
about — see below.

The workaround: one site

• One source site, not the LUT family the defect guessed. The trigger is
  rgb2hsv's p.zw constant lane pair, which LLVM materialises as
  [2 x float]. snoise2's gradient LUT — the defect's named suspect —
  compiles unchanged, as do worley2/3, gnoise3_tile, psrdnoise2/3 and
  snoise3; all are present in the built image. The reported constant simply
  belonged to a different function than the one that failed.
• Technique: integer bit patterns (f32::from_bits over a bool-selected
  u32), const-evaluated from the original literals. Chosen over an
  arithmetic rewrite because it is provably bit-identical — sign-of-zero is
  the specific hazard arithmetic would have introduced.
• Bit-equivalence is pinned, not argued: the pre-workaround form is kept
  verbatim in the test module as an oracle and compared lane-by-lane over a
  grid crossing g == b, plus -0.0 and NaN.
• The site carries a comment naming the defect and stating it is upstream, not
  preference, shaped for the issue URL once filed.

The gate flip: attempted, measured, reverted

Making --features float-f32 unconditional took xtn.q32 from 849/849 files
to 522/849, on link failures. Cause is capacity, not codegen:

build	.text	free IRAM (112 KiB)
Q32 only	66,300 B	48,388 B
float-f32	113,757 B	931 B

rt_emu::xt_image places compiled shader code in exactly that gap, so small
shaders fit and everything else fails to link. That is a second, independent
defect, filed as
docs/defects/2026-08-01-xt-f32-builtins-exhaust-the-emulator-code-region.md
with the measurements and three candidate resolutions (widen the modeled code
region / give the shader its own region / split the f32 feature so the
generative-noise family — most of the 47 KB — stays rv32-only).

So LP_XT_BUILTINS_F32 stays, with its comment rewritten to say why it now
exists. Reporting this rather than papering over it.

The pipeline test

a_builtin_routed_float_op_resolves_and_runs is no longer #[ignore]d.
Removing the attribute was not enough: the file's link_blob resolves only
the module's own functions and loads at the code region's base, where the
builtins image already lives, so __lp_lpir_ffloor_f32 could never resolve.
Added a builtins-linked run path using rt_emu::xt_image's layout. It skips
loudly when the resident image lacks the f32 family, so one blocked capability
does not redden a suite.

Validation

• LP_XT_BUILTINS_F32=1 ./scripts/build-builtins-xt.sh — 48 builtins, 82 native-f32 ✅ (was the definition of done)
• just check — EXIT=0
• cargo test -p lps-builtins --all-features — 380 passed
• cargo test -p lpvm-native --test xt_pipeline_f32 — 16/16, both with and without the f32 image
• xtn.q32 filetests — 6336/6336, 849/849 files (unchanged from base)
• rv32/Q32 untouched, no baselines regenerated, C6 image unaffected (float-f32 is off for it)

🤖 Generated with Claude Code