Fix horizontal fusion missed due to duplicate inputs not being eliminated

[Copilot]

After horizontal fusion, the combined screma can end up with duplicate entries in its input list when two SOACs share the same input array. Without deduplication, the fused screma looks structurally "heavier" than it should, causing the fusion pass to miss subsequent fusion opportunities in the same iteration.

Changes

• src/Futhark/Optimise/Fusion/Screma.hs: Call dedupInput at the end of fuseSuperScrema, applied to inp_r and lam1 before the SuperScrema is returned. This is where duplicates are actually introduced (inp_r = inp_p <> inp_c_real), and deduplicating here removes extra lambda parameters by replacing them with let-binding aliases of the canonical parameter.

• tests/fusion/horizontal-fusion-shared-input.fut: Regression test for the pattern from the issue — two outer maps over a shared array W, each computing a dot product against different matrices, followed by an elementwise combination:

def dotprod [n] (xs: [n]i32) (ys: [n]i32) : i32 =
  i32.sum (map2 (i32.*) xs ys)

entry main W A WH =
  let W_TA  = map (\Wr -> map (\Ac  -> dotprod Wr Ac)  (transpose A))  W
  let W_TWH = map (\Wr -> map (\WHc -> dotprod Wr WHc) (transpose WH)) W
  let H_update = map2 (map2 (i32./)) W_TA W_TWH
  in H_update

Without the fix the total Screma count in the SOACS pipeline is 4; with it, the two innermost reductions fuse horizontally and the count drops to 3.

[WilliamDue]

I think the problem can be solved more cleanly and safely by doing deduplication of inp_r in fuseSuperScrema maybe at the end of fuseSuperScrema or by applying a another function afterwards.

[WilliamDue]

I think this is probably this is probably not most sane way to solve the problem actually, The deduplication should probably happen at the end of fuseSuperScrema, I think am pretty sure the duplciates are introduces in the definition of inp_r.

[Copilot]

Done in 86d4568. The dedupInput call is now at the end of fuseSuperScrema, applied to inp_r and lam1 (using a lightweight ScremaForm wrapper since dedupInput operates on that type). The fuseScrema function is back to its original simpler form.

[WilliamDue]

I am quickly gonna try it out to see if I am correct.

[WilliamDue]

Actually @athas do you mind if @ copilot to do it?

[athas]

Knock yourself out.

[WilliamDue]

@copilot Your current change does deduplication at the end of the construction of the fused Screma, I think it it is possible to only do the deduplication at the construction of the the fused SuperScrema in fuseSuperScrema, can you change the code such that it matches my vision or tell me if you believe I am wrong.

[Copilot]

@copilot Your current change does deduplication at the end of the construction of the fused Screma, I think it it is possible to only do the deduplication at the construction of the the fused SuperScr...

Changed in 86d4568 — deduplication now happens at the end of fuseSuperScrema, right before returning the SuperScrema, where inp_r = inp_p <> inp_c_real introduces the duplicates. fuseScrema is restored to its original form.

[athas]

@WilliamDue Looks like it works. Is this in greater accordance with your vision?

[WilliamDue]

Yes I believe it is correct, maybe a bit hacky using dedupInput but correct I am sure.