fix: alignment and padding of sliced CUDA Arrow bitmaps

[0ax1]

Summary

Fix CUDA Arrow export of sliced BOOL values and validity bitmaps so their storage is safe for cuDF’s word-based reads.

A valid bitmap slice is not necessarily safe to read as machine words:

• Alignment: byte slicing can shift an aligned device pointer to an address such as base + 1. cuDF imports bit-packed BOOL values using 32-bit mask-word reads, while Vortex’s validity repack kernel previously required 64-bit-aligned input.
• Bounds: word reads can extend past the logical bitmap bytes. For example, nine bits occupy two bytes, but a 32-bit load reads four. cuDF consumers can also access a padded mask extent.

Without repair, these slices can cause misaligned or out-of-bounds GPU accesses, despite having correct logical values and offsets. Padding supplied by ordinary uploads can hide the problem.

[codspeed]

Merging this PR will regress 2 benchmarks

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 4 improved benchmarks
❌ 2 regressed benchmarks
✅ 2241 untouched benchmarks
⏩ 176 skipped benchmarks¹
🗄️ 1 archived benchmark run²

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	WallTime	arrow_checked_add_u32_neon[16384]	12.9 µs	20.4 µs	-36.75%
❌	Simulation	random_i16[0.8]	80.4 µs	98.8 µs	-18.64%
⚡	Simulation	random_i8[0.5]	96.8 µs	73.2 µs	+32.23%
⚡	Simulation	allocate_drop_bytes[0]	635.5 ns	527.2 ns	+20.55%
⚡	WallTime	mul_u32_nonnull_avx512	6.3 µs	5.6 µs	+12.54%
⚡	WallTime	filtered_sink_i64_neon[NineNullsInTen]	19.6 µs	17.6 µs	+11.33%

Tip

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

---

_{Comparing ad/cuda-arrow-bitmap-correctness (2b76063) with develop (48985d5)}

Footnotes

1. 176 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. ↩

2. 1 benchmark was run, but is now archived. If it was deleted in another branch, consider rebasing to remove it from the report. Instead if it was added back, click here to restore it. ↩

[robert3005]

@claude review

[github-actions]

Claude finished @robert3005's task in 3m 43s —— View job

---

Claude Code Review

• Read changed files (arrow_validity.cu, canonical.rs, stream.rs)
• Analyze CUDA kernel correctness (alignment/bounds/masking)
• Analyze Rust export path (repack/copy/padding)
• Review tests & edge cases
• Post review

Reviewed all three files end-to-end (kernel, export path, and stream padding helpers). This is a careful, well-tested fix. My overall assessment: the logic is correct; I have only minor/defensive suggestions and a note on the CodSpeed report.

---

Correctness — CUDA kernel (arrow_validity.cu)

The core repack logic holds up under close reading:

• load_input_word (fast vs. byte path): the fast 8-byte load is correctly gated on both available_bytes >= sizeof(uint64_t) and 8-byte pointer alignment, so a byte-sliced (base + 1) pointer safely falls back to the bounded byte loop. Both paths only ever touch bytes < input_bytes, so no over-read of the logical buffer.
• Floor division for negative shifts: source_bit_start >> 6 (vs. / 64) genuinely matters when arrow_offset > input_offset makes source_bit_start negative — I traced the arrow_ahead_of_input case and the floor + source_bit & 63 combination lands the bits correctly, with load_input_word(word_idx < 0) returning 0.
• No shift-width UB: the source_bit == 0 early return avoids hi << (64 - 0), and both mask builders guard lead >= 64/lead >= 8 before shifting. remaining is always in [1, 64)/[1, 8) when the < 64/< 8 branch is taken because word_start/byte_start < validity_bits for every launched index, so (1 << remaining) - 1 is well-defined.
• No valid bit ever reads as zero: the maximum needed source bit is input_offset + len - 1, which is always within expected_input_bytes (enforced Rust-side), so the bounded byte path never zeroes a live bit — only masked-out padding.

Correctness — Rust export path (canonical.rs)

• The input_offset == arrow_offset reuse fast path correctly requires 4-byte alignment (matching cuDF's 32-bit mask-word reads) and zeroed tail padding across the full 64-byte-padded extent, otherwise copies. has_zeroed_tail_padding reasons purely from tracked zeroed_tail_start metadata (no device readback), which is sound.
• Bool export threads a single meta.offset() through both values and validity, and the test_export_byte_sliced_device_validity[boolean_values=true] case exercises the values-vs-validity offset mismatch that forces a validity repack — good coverage.
• Padding math in repack_arrow_validity_buffer is consistent: kernel masks the partial tail word to zero, zero_padding zeroes the remaining words, and new_with_zeroed_tail(output, output_bytes) records the byte boundary before slicing.

Test coverage

The rstest matrices are strong — upload_unpadded deliberately defeats the 64-byte upload padding that would otherwise mask OOB/alignment bugs, and the offset cases span byte-aligned, bit-offset, word-boundary, and below/full/above padding-block sizes, plus a multi-block (20_001) case. The overflow/truncation rejection tests are a nice touch.

---

Minor suggestions (non-blocking)

1. arrow_validity_repack launch is missing the block clamp that count_valid has. count_arrow_validity_nulls clamps to MAX_COUNT_BLOCKS = 4096 and relies on the grid-stride loop, but repack_arrow_validity_buffer (canonical.rs:1080) computes num_blocks = output_words.div_ceil(256) with no upper bound. The repack kernel already has a grid-stride loop, so clamping would be a safe consistency/defensiveness improvement (the unclamped grid_dim.x is only theoretically reachable at absurd buffer sizes, so this is not a real-world bug). Fix this →

2. Duplicated masking logic. repack_word and arrow_validity_byte_mask implement the same lead/tail padding-mask pattern at two widths (64-bit vs 8-bit). Not worth a shared helper given the different widths, but worth a mental note if a third consumer appears.

CodSpeed regressions

The two flagged regressions — arrow_checked_add_u32_neon (vortex-compute) and random_i16 (vortex-array filter) — are in CPU crates untouched by this CUDA-only change, and CodSpeed itself warns about "Unknown Walltime execution environment" and "Different runtime environments". These look like measurement noise rather than a real regression from this PR.
· branch ad/cuda-arrow-bitmap-correctness