Bug in SROA

I'll minimize this later today, but I found a bug in SROA. It occurs when not inlining first.

Branch: cava_bughunting (dd6a5c2ad84224385abb9e2bcb232cd586dd9bb6)

Command: cargo run --bin juno juno_samples/cava.jn

Output:

thread 'main' panicked at hercules_opt/src/sroa.rs:280:49:
index out of bounds: the len is 85 but the index is 85

assigned to @aaronjc4

The bug here is (I believe from just looking at it) that there is a write node using the result of a call but that call node gets replaced early on and so isn't in the type map. Will think and try to push something a little later today

mentioned in commit 738383c9

I don't think the issue is resolved by 738383c9595a96e6135b083196ab2a46eed02f5b, I pushed a5fab202b7b9b20b61c0d171db72978306d231c3 which prints out the passes as they run for more clarity. When running cargo run --bin juno juno_samples/cava.jn --verify-all, I see:

Ran pass: Verify
Ran pass: GVN
Ran pass: Verify
Ran pass: PhiElim
Ran pass: Verify
Ran pass: DCE
Ran pass: Verify
Ran pass: InterproceduralSROA
Ran pass: Verify
Ran pass: SROA
thread 'main' panicked at hercules_opt/src/pass.rs:649:26:
PANIC: Failed to verify Hercules IR module.: "Array constant must store an explicit array type."

This is on the full cava example - I can start with smaller examples first so that it's not as difficult to debug, but I thought I'd post this here in the meantime.

FWIW, the following Juno file that Ryan was trying to use now runs into I presume the same error:

fn test<x, y : usize>(a : i32[x, y]) -> (i32[x, y], i32[x,y]) {
  let b : i32[x,y] = a;
  return (a, b);
}

fn main<x, y, z : usize>() -> i32[y, z] {
  let n : i32[y, z];
  let res = test::<y, z>(n);
  return res.1;
}

And fails like:

Ran pass: Verify
Ran pass: PhiElim
Ran pass: Verify
Ran pass: Inline
Ran pass: Verify
Ran pass: InterproceduralSROA
Ran pass: Verify
Ran pass: SROA
thread 'main' panicked at hercules_opt/src/pass.rs:649:26:
PANIC: Failed to verify Hercules IR module.: "Array constant must store an explicit array type."

Commit 7b380e936f76a5e8edd452c8fecb81b8b918d35f should resolve the issue with Cava. I'm unable to reproduce Ryan's issue, on my end that example fails in verifying the result of inter SROA.

So on main it fails at SROA, and on cava_bughunting it fails at Inter-SROA. Looking into this now.

(Cherrypicking the above fix to main makes the example work, until sched_gen needs a non-root array type, but that failure is expected rn)

So re-enabling inlining "fixes" the inter-sroa verification issue. However, inter-sroa should work without needing to inline first.

Going to merge cava_bughunting for now to get fixes on main, I'll open a separate issue for the inter-sroa bug.

mentioned in commit 2f6d9505

closed with merge request !64 (merged)