[mhk197]

Summary

FoRScheme bit-packed its child by calling BITPACKING_V1 directly, without declaring the bit-packing IDs. The builder kept FoR when fastlanes.bitpacked (or vortex.patched) was disallowed, so the write failed, and the child never used fastlanes.bitpacked.v2. FoR now holds the BitPackingScheme it uses, declares that scheme's IDs, and refines it alongside the references.

Closes #10751.

Changes

• FoRScheme gets a bitpacking field, and produced_encodings appends its IDs.
• refine picks the references and the child's bit widths independently (four statics).
• The child is compressed with FoR's context rather than a leaf one, so v2 block offsets can cascade.

Core-edition and CUDA output is unchanged. Sessions that allow fastlanes.bitpacked.v2 now get blocked children under FoR (fused decode from #10251).

Testing

• builder.rs: FoR is dropped without fastlanes.bitpacked and kept with it.
• for_.rs, tests/for_config.rs: FoR refines to a blocked child when fastlanes.bitpacked.v2 is allowed, and the compressed output serializes it.

Follow-up

Excluding BitPackingScheme by scheme ID still doesn't stop FoR from bit-packing (documented on FoRScheme).

[codspeed]

Merging this PR will degrade performance by 15%

4 warnings, 1 note

⚠️ Walltime results may be unreliable

Some benchmarks used the Walltime instrument outside CodSpeed Macro Runners, which can make the results inconsistent.

Learn more about Macro Runners

See affected benchmarks

⚠️ Unable to measure the execution of 2 benchmarks

These benchmarks measured no execution time, so their results are not comparable and count as unchanged. This usually happens when the compiler removes the code under test.

Prevent compiler optimizations

See affected benchmarks

⚠️ 16 benchmarks are dominated by system calls

System calls cannot be simulated consistently and are left out of the measure. The reported value understates the real cost. Switch to the Walltime instrument to measure them.

Learn more about system calls

See affected benchmarks

⚠️ Base and head ran on different runner types

Some benchmarks with significant performance changes were compared across different runner types, so the changes might not come from the code. Run base and head on the same runner type, or use CodSpeed Macro Runners for more stable results.

Learn more about Macro Runners

Open the report in CodSpeed to investigate

ℹ️ 40 benchmarks have no flamegraph

The flamegraph wasn't generated: the symbols of the profiling trace could not be resolved, because no information about the language frames was collected.

See affected benchmarks

⚡ 2 improved benchmarks
❌ 4 regressed benchmarks
✅ 2402 untouched benchmarks
⏩ 12 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Walltime	filter_neon[8]	893 ns	1,600 ns	-44.19%
❌	Walltime	filter_neon[64]	1.7 µs	2.6 µs	-33.9%
❌	Walltime	filter_neon[80]	2.6 µs	3.4 µs	-24.31%
❌	Walltime	threshold_neon[80]	3.5 µs	3.9 µs	-11.28%
⚡	CPU Simulation	test_repeated_scan_scalar_at[int]	318.8 µs	237.4 µs	+34.31%
⚡	Walltime	bitpack_blocked_compress_avx2	7.6 µs	6.7 µs	+13.39%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing mk/for-bitpacking-mode (055df1d) with develop (91b38f4)}

Footnotes

1. 12 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[mhk197]

@connortsui20 I dont love having 4 different static variants of this...