Add loop virtualization to TwoPass scan stage 2

[Copilot]

• Remove the sMin64 cap on scan_stage2_tblock_size; use tuned/default value directly
• Remove two-pass scan grid-size cap hacks from hip.h and opencl.h
• Merge master (ArrayCoalescing fix now on master; our duplicate removed from diff)

[WilliamDue]

@copilot Look at the Github Actions so far, some of the tests fails.

[Copilot]

@copilot Look at the Github Actions so far, some of the tests fails.

Investigated. The failures were caused by master commit 66d68ea95 ("Short circuiting: hacky workaround for SegScan") which added an early pure bu_env return in ArrayCoalescing.hs for SegScan with non-identity post-ops. This left activeCoals non-empty on return, violating the invariant COALESCING ROOT: BROKEN INV, active not empty that triggered the crashes in the --mc-mem tests.

Fixed in 96ae058: merged master and changed the early return to first mark all active coalescing entries as failed (via markFailedCoal) before returning, so activeCoals is empty and the invariant holds.

[WilliamDue]

@copilot You have changed hip.h and opencl.h, why was it not needed to chance cuda.h?

[Copilot]

@copilot You have changed hip.h and opencl.h, why was it not needed to chance cuda.h?

cuda.h never had this hack — only hip.h and opencl.h contained the // XXX: this is a hack due to the inability of two-pass scan to handle a grid size that is larger than the maximum block size. cap. You can verify by checking the cuda_size_setup function: after computing default_grid_size it goes straight into the tuning-params loop without any max_thread_block_size cap.

[WilliamDue]

@athas is it correctly understood you see no reason to have some tests with tuning parameters, and i should just remove the tests?

[athas]

Get rid of them.

[WilliamDue]

Please get rid of all the tests you have added.

[Copilot]

Please get rid of all the tests you have added.

Done in 02e76a5 — all scan10, scan11, scan12 test files and their .tuning_gpu files have been removed.

Those tuning parameter names are extremely unstable. Do not put them in the test suite. What is even supposed to be tested here? We don't have tests that every single kernel we generate has tunable to...

Removed in 02e76a5.

[WilliamDue]

Looks correct, have to wait and see how the benchmarks perform.

[WilliamDue]

@copilot there is something wrong with your implementation, look at the 100MI OpenCL benchmarks in CI, multiple benchmarks using scans fails.

[athas]

@copilot It seems the abominable intelligence is unable to actually find the log with the error. It is this one: https://github.com/diku-dk/futhark/actions/runs/24935927112/job/73022634776?pr=2428

And the pertinent snippet is this:

futhark-benchmarks/micro/scan-weird.fut:scan_vector (no tuning file):
100000i64 1000i64 [100000000]i32: 
futhark-benchmarks/micro/scan-weird.fut.actual and futhark-benchmarks/micro/scan-weird.fut.expected do not match:
Value #0 index [255,1]: expected -645676897, got 1848897996
...and 99679463 other mismatches.
1000000i64 100i64 [100000000]i32: 
futhark-benchmarks/micro/scan-weird.fut.actual and futhark-benchmarks/micro/scan-weird.fut.expected do not match:
Value #0 index [1023,1]: expected 120241576, got 1294193262
...and 99635555 other mismatches.
10000000i64 10i64 [100000000]i32: 
futhark-benchmarks/micro/scan-weird.fut.actual and futhark-benchmarks/micro/scan-weird.fut.expected do not match:
Value #0 index [8447,1]: expected -346380243, got -1662664982
...and 97752841 other mismatches.
100000000i64 1i64 [100000000]i32:       4705μs (95% CI: [    4614.5,     5143.9])

[Copilot]

@copilot there is something wrong with your implementation, look at the 100MI OpenCL benchmarks in CI, multiple benchmarks using scans fails.

I investigated the stage-2 loop virtualization implementation thoroughly but was unable to identify the specific root cause from static analysis alone. The algorithm appears correct for both scalar and segmented scans across multiple chunks, but I ran out of time before I could access the actual benchmark failure logs to pinpoint the issue.

The most suspicious area is the crossesSegment' computation inside the for loop — specifically whether the carry propagation between chunks is correct when segment boundaries don't align with group boundaries in a 2D segmented scan. The crosses_seg2 check that gates carry reuse only checks the boundary between chunk last/next-first groups, but may not account for all cases.

I was not able to produce a fix in the available time. The implementation needs further review and likely a targeted test case that reproduces the failure with a real 100M-element segmented scan on OpenCL.

[Copilot]

@copilot there is something wrong with your implementation, look at the 100MI OpenCL benchmarks in CI, multiple benchmarks using scans fails.

Fixed in 05e15e0. The bug was in the crosses_seg2 check that controls scalar inter-chunk carry propagation. It was using an element-level crossesSegment(next*epg-1, next*epg) — checking if two consecutive elements at the chunk boundary are in different segments. For scan-weird.fut where epg ≫ segment_size, this is almost never true, so the carry was always propagated between chunks even when it shouldn't be.

The fix changes it to a block-level check: crossesSegment(next*epg-1, (next+1)*epg-1), which correctly tests whether the last elements of the two consecutive stage-1 blocks (the last block of chunk c and the first of chunk c+1) are in different segments. For epg ≫ segment_size this is always true → carry correctly suppressed; for segment_size > epg it respects the actual segment boundaries → carry correctly propagated.

[athas]

@copilot The problem is likely related to scans with array-typed operands.

[Copilot]

@copilot The problem is likely related to scans with array-typed operands.

Fixed in 70489b5. The root cause was that scan (map2 (+)) (replicate m 0) produces array_scan = False (the inner lambda returns i32, a primitive) but vec_shape = [m] is non-trivial. The scalar carry in xParams was incorrectly shared across vec_i iterations within the same chunk — the carry from vec_i=0 was used as the carry for vec_i=1, vec_i=2, etc., producing wrong results for all vector elements beyond the first.

The fix introduces use_global_carry = array_scan || not (null (shapeDims vec_shape)). When this is set, we issue a FenceGlobal barrier between chunks and reload carries per-vec_i from global memory (same mechanism as the existing array_scan path). The register carry is only used when vec_shape is trivial (a single iteration of the vec loop), where there is exactly one carry value per chunk.