feat: rv64 cuda sha2

[876pol]

Resolves INT-7530.

[github-actions]

Claude encountered an error —— View job

---

I'll analyze this and get back to you.

[github-actions]

Claude encountered an error —— View job

---

I'll analyze this and get back to you.

[github-actions]

Claude finished @876pol's task in 2m 18s —— View job

---

Code Review: rv64 cuda sha2

• Gather context and review PR diff
• Review each changed file
• Post review feedback

---

LGTM — This is a clean RV32→RV64 migration for the SHA2 CUDA trace generation code. All changes are consistent with the Rust-side definitions already on the base branch.

Changes Summary

File	Change
variant.cuh	SHA2_READ_SIZE/SHA2_WRITE_SIZE 4→8; removed redundant SHA2_MAIN_READ_SIZE; updated BLOCK_READS/STATE_READS to use SHA2_READ_SIZE
columns.cuh	RV32_REGISTER_NUM_LIMBS → RV64_WORD_NUM_LIMBS for pointer limb arrays
sha2_main.cu	Same RV32→RV64 constant rename for pointer byte arrays and range check shift computation
cuda.rs	Sha2Rv32GpuBuilder → Sha2Rv64GpuBuilder, Sha2Rv32Config → Sha2Rv64Config, config.rv32i/rv32m → config.rv64i/rv64m
mod.rs	Fixed re-export to use the correctly-named Sha2Rv64GpuBuilder instead of aliasing the old Sha2Rv32GpuBuilder

Verification

• Rust-side SHA2_READ_SIZE = 8 and SHA2_WRITE_SIZE = 8 (config.rs:9-10) — matches the CUDA constants.
• Rust-side Sha2Rv64Config fields are rv64i and rv64m (mod.rs:50-52) — matches the CUDA builder references.
• RV64_WORD_NUM_LIMBS = 4 equals the old RV32_REGISTER_NUM_LIMBS = 4 (constants.h:6,13), so array sizes and memcpy(&header->dst_ptr, sizeof(uint32_t)) remain compatible.
• RV64_CELL_BITS = 8 equals RV32_CELL_BITS = 8, so the shift computation is unchanged.

Minor pre-existing observation

In sha2_main.cu:68-73, needs_range_check[3] duplicates needs_range_check[2] (both are input_ptr_bytes[RV64_WORD_NUM_LIMBS - 1]). This matches the Rust-side AIR (air.rs:230-231) which has the same duplication with a comment noting "needs_range_check must have even length", so this is intentional. No action needed.

No issues found.

[shuklaayush]

hmm we should consolidate these constants at some point so there's a single source of truth. feels like this should just be default_block_size

[github-actions]

Claude finished @shuklaayush's task in 2m 17s —— View job

---

Code Review: rv64 cuda sha2

• Gather context and review PR diff
• Review each changed file
• Post review feedback

---

LGTM — Clean, mechanical RV32→RV64 migration for the SHA2 CUDA trace generation code. All changes are consistent with the Rust-side definitions on the base branch.

Changes Summary

File	Change
variant.cuh	SHA2_READ_SIZE/SHA2_WRITE_SIZE 4→8; removed redundant SHA2_MAIN_READ_SIZE; BLOCK_READS/STATE_READS/STATE_WRITES now computed from SHA2_READ_SIZE/SHA2_WRITE_SIZE
columns.cuh	RV32_REGISTER_NUM_LIMBS → RV64_WORD_NUM_LIMBS for pointer limb arrays
sha2_main.cu	Same RV32→RV64 constant rename for pointer byte arrays and range check shift computation
cuda.rs	Sha2Rv32GpuBuilder → Sha2Rv64GpuBuilder, references config.rv64i/rv64m instead of config.rv32i/rv32m
mod.rs	Fixed re-export to use correctly-named Sha2Rv64GpuBuilder

Verification

• Rust-side SHA2_READ_SIZE = 8 and SHA2_WRITE_SIZE = 8 (config.rs:9-10) — matches the CUDA constants in variant.cuh.
• Rust-side Sha2Rv64Config fields are rv64i and rv64m (mod.rs:50-52) — matches the CUDA builder references in cuda.rs.
• RV64_WORD_NUM_LIMBS = 4 (constants.h:13) equals the old RV32_REGISTER_NUM_LIMBS = 4 (constants.h:6), so array sizes and memcpy(&header->dst_ptr, sizeof(uint32_t)) remain compatible.
• RV64_CELL_BITS = 8 (constants.h:14) equals RV32_CELL_BITS = 8, so the shift computation 1u << (RV64_WORD_NUM_LIMBS * RV64_CELL_BITS - ptr_max_bits) is unchanged.
• DEFAULT_BLOCK_SIZE = 8 (constants.h:21, config.rs:116) — same value as the new SHA2_READ_SIZE/SHA2_WRITE_SIZE.

Notes

Re: @shuklaayush's comment on consolidating constants — Agreed. SHA2_READ_SIZE and SHA2_WRITE_SIZE are both 8, matching DEFAULT_BLOCK_SIZE. If all extensions converge on DEFAULT_BLOCK_SIZE for their memory access granularity, these could reference a single source of truth. Not blocking for this PR.

Pre-existing observation: In sha2_main.cu:68-73, needs_range_check[3] duplicates needs_range_check[2] (both are input_ptr_bytes[RV64_WORD_NUM_LIMBS - 1]). This matches the Rust-side AIR (air.rs:230-231) which has the same pattern with a comment noting "needs_range_check must have even length", so this is intentional padding. No action needed.

No issues found.