[bong-water-water-bong]

What

tools/ci/hrx_f16_narrowing.py matched the narrowing by the substrings f32 to f16 and truncf. The vector spelling matches neither, and it is the majority of the corpus:

%h = vector.fptrunc %v : vector<4xf32> to vector<4xf16>

• fptrunc ends in trunc, not truncf, so truncf never fires on it;
• vector<4xf32> to vector<4xf16> is not the scalar phrase f32 to f16.

So 132 of the 233 narrowing lines were invisible and the ratchet guarded 25 of the 51 narrowing bodies.

This changes the marker from string containment to the type pair, as two regexes -- f32 to f16 (scalar, unchanged in behaviour) and f32>\s+to\s+vector<\d+xf16> (the vector form, any lane count) -- and re-baselines.

Measured, on the corpus at the engine's pin 2b7960bae

Corpus extracted from that sha (git blobs, 124 .loom files), then the tool's own --check / --write against it:

	bodies
old matcher (baseline, unchanged)	25
patched matcher, old baseline -> --check	FAIL: 27 new, 1 stale of 25
patched matcher -> --write	51
patched matcher, new baseline -> --check	51, none new, none stale; 10 carry a guard marker

The one stale line is loom-libs/motifs/unary_f32_apply.loom: it is in the baseline and no longer narrows at this pin, so it is dropped by the same --write. That is the engine#1728 rename lesson working as designed rather than a surprise.

The issue's "52 bodies" and this "51" differ by one; the number here is what the corpus at 2b7960bae actually contains, and --write is the authority either way.

Test

--self-test gains one arm, next to the existing drift/rename/guard/comment ones:

ok   the vector form `vector<Nxf32> to vector<Nxf16>` is a narrowing body
ok   the vector body drifts like any other body

and the whole self-test stays green: hrx_f16_narrowing self-test: ok.

Risk

The matcher now lists 26 more bodies than before, none of which is a new narrowing in the corpus -- they were always there. That is the point of the ratchet, but a reviewer should expect the baseline diff to be prose-free and body-name-only, and any future vector narrowing in one of those bodies will now be caught. No behaviour change to any build; this is the CI listing tool only.

[bong-water-water-bong]

Closing as a duplicate of #2222, which is the earlier PR with the same matcher semantics (I found it after opening this — the dedupe pass I should have run before).

Both #2222 and this one drop the bare truncf marker and drop the stale baseline line, landing on 51 bodies. For the record, the measurement that decided between the three open fixes of #2219:

PR	matcher	baseline bodies	stale line dropped
#2220	keeps |truncf	52 (25 + 27)	no
#2222	type pair only	51	yes
#2223 (this)	type pair only	51	yes

The pinned corpus (2b7960bae, 124 .loom blobs) contains exactly one body with a bare truncf that is not fptrunc -- loom-libs/motifs/unary_f32_apply.loom -- and it spells vector.truncf %values : vector<4xf32>, a truncation within f32 that names no f16 type. So "52 bodies" in #2219 counts a false positive; the corpus has 51.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 2219 - Partially compliant Compliant requirements: Update the f16 narrowing ratchet to match the vector form of fptrunc operations Ensure the ratchet now correctly identifies 52 narrowing bodies instead of just 25 Re-baseline the hrx_f16_narrowing.txt file to include all 51 narrowing bodies (52 minus one stale body) The fix is measured on the corpus at the engine's llama.cpp pin 2b7960bae Non-compliant requirements: None Requires further human verification: None

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Regex Pattern Matching The change updates the narrowing detection logic from simple substring matching to regex-based pattern matching. This improves accuracy by correctly identifying both scalar and vector forms of f32 to f16 narrowing operations. The regex patterns ensure that both f32 to f16 and f32>\s+to\s+vector<\d+xf16> are matched, which was previously missed. NARROW = (re.compile(r"f32 to f16"), re.compile(r"f32>\s+to\s+vector<\d+xf16>"))