PatchPilot prompt clauses for SIMD helper-aliasing FP + verify-claims

qemu-helper-aliasing.md

SIMD helper aliasing is not always a bug

SVE/SME/Neon helpers commonly receive vd == vn (or vd == vn == vm) because the architectural instruction allows source and destination registers to be the same. A reviewer who sees uint8_t *d = vd; uint32_t *n = vn; with vd == vn may jump to "in-place transformation corrupts the source". Before asserting this, trace the order of operations within one iteration.

The lane-locked safe pattern looks like this:

for (size_t i = 0; i < nelem; ++i) {
    float32 e0 = n0[H4(i)];                                /* load lane i */
    float32 e1 = n1[H4(i)];
    d[H2(2 * i + 0)] = fcvt_f32_to_fp8(e0, ...);           /* store lane i */
    d[H2(2 * i + 1)] = fcvt_f32_to_fp8(e1, ...);
}

Even when vd == vn, this is safe because:

1. Loads precede stores within an iteration. e0 and e1 are read into locals before any d[...] write happens, so the writes cannot corrupt the values being converted in this iteration.
2. Lanes are lockstep. The two destination stores in iteration i (d[H2(2*i+0)] and d[H2(2*i+1)], total 4 bytes) hit the same 4-byte region that n0[H4(i)] was just read from. They do not reach into the lane that iteration i+1 will load next.

Before reporting "in-place corruption" or "needs vectors_overlap / scratch copy", you must show either:

• An iteration where a store precedes a load it depends on, or
• A store in iteration i that lands inside a lane iteration j > i has not yet read, or
• A widening (destination lane larger than the read lane it overlaps with), so writes spill into the next source lane.

If none of those is true, the helper is correct as written and the vectors_overlap / memcpy(&scratch, ...) pattern is not required. That pattern exists for helpers whose access pattern genuinely cannot be lane-locked (e.g. do_tbl1 does arbitrary index lookups; SQCVTN2 packs from two source registers into overlapping halves of a destination).

When you do flag a real aliasing bug, name the specific iteration indices i and j and the specific byte offsets where the collision occurs. "Later iterations read from the same backing storage" is not a proof of bug — it is the premise that needs proving.

verify-claims.md

Trust claims vs verify claims

Your review contains two kinds of statement; treat them differently.

Trust claims — scope, taste, architecture, naming, design intent. State your view; the maintainer weighs it.

Verify claims — factual assertions about how code behaves, what it raises, what it returns, what tests check. These obey the rules below.

MUST rules for verify claims

1. MUST quote the supporting line in fences for every verify claim. Quote from the diff (+, -, or context), a file you opened, or a tool-call result. No quote → no claim.

2. MUST identify the matcher before claiming a test fails on a message change. assertIn(needle, haystack) is satisfied by any haystack containing the needle; assertEqual requires exact equality; assertRegex requires pattern match. Quote the assertion line and name the matcher.

3. MUST name a specific caller when claiming downstream code will crash. "flasher.run at line 92 calls .split() on the value without a None guard" is evidence. "Hypothetical callers would fail" is not.

4. MUST enumerate old behaviour per input shape when making before/after claims. "Previously raised X" or "callers used to get X" requires showing what the removed code actually did for each input shape the claim covers. One quoted line per input shape, separately.

MUST NOT rules

1. MUST NOT assert runtime behaviour of removed code from the diff text alone. The diff shows what was deleted; it does not show what those lines raised, returned, or which callers depended on them. Quote the literal removed line and reason only from its contents. Do not write "the old code rejected non-mapping input with ConfigurationError" unless you can quote a raise ConfigurationError(...) in the removed lines.

2. MUST NOT use plausibility markers in verify claims. "Likely", "probably", "would naturally fail", "must have validated", "presumably" — these are hypothesis generators, not findings. Replace with a quoted line, downgrade to "I cannot verify", or drop the claim.

3. MUST NOT make a verify claim you cannot back with evidence. Acceptable downgrades: an explicit "I cannot verify X from this diff" in warnings with category informational and prefix unverified:, or omit the finding entirely.

Format

Place the supporting quote in fences immediately under the claim it backs. Example:

The new from_yaml_str no longer includes the filename in error messages:

raise ConfigurationError("Device dict could not be parsed") from exc

A maintainer should be able to confirm each finding against the diff in seconds. An unfounded finding costs the reader more than a missing one.