feat: return unsolvable opcode from CircuitSimulator

[guipublic]

Description

Problem*

Resolves #8774

Summary*

The compiler crash is transformed into an error during execution by using non solvable witness to represent unresolved loads.

Additional Context

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[asterite]

I wonder, the SSA in the issue is this one:

acir(inline) predicate_pure fn main f0 {
  b0():
    v0 = make_array [] : [&mut u1; 0]
    constrain u1 0 == u1 1, "Index out of bounds"
    v4 = array_get v0, index u32 0 -> &mut u1
    v5 = load v4 -> u1
    return v5
}

I guess it crashes because there's an array get of an empty array, then loading that value...

Could we instead have an SSA pass that recursively removes values that can't happen? I'm thinking that v4 can't succeed regardless of the index because the array is empty, so we'd remove that instruction. Now that v4 was removed, v5 should be removed too because it uses that, etc. The tricky part is removing the return, or replacing it with a zeroed value I guess.

[asterite]

Actually, this might be simpler. In this SSA:

acir(inline) predicate_pure fn main f0 {
  b0():
    v0 = make_array [] : [&mut u1; 0]
    constrain u1 0 == u1 1, "Index out of bounds"
    v4 = array_get v0, index u32 0 -> &mut u1
    v5 = load v4 -> u1
    return v5
}

there's a constrain that will always fail. Then we can remove any subsequent instructions in that block and replace the terminator values with zeroed values (the "zeroed values" logic was introduced in a recent PR).

[asterite]

I'll try the above in a separate PR, just because now I'm curious about it 😊

[TomAFrench]

This is superceded by #9008 right @asterite?

[asterite]

@TomAFrench Yes. I didn't know if this PR was also wanted, though I guess now unresolved loads can't (shouldn't) happen anymore.

[guipublic]

This PR is different than #9008 and removes a compiler crash. I don't think there is a 100% guarantee that loads will always be removed.

[aakoshh]

About load removal: I added a panic if they are still present after DIE in #9018

I guess this is something that could be turned into a warning if we find a case we cannot eliminate.

[jfecher]

Let's revert the unreachable on Instruction::Load but we can keep the callstack changes

[guipublic]

I reverted the changes to unresolved loads.

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Test Suite Duration'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: e1af39d	Previous: f073164	Ratio
test_report_AztecProtocol_aztec-packages_noir-projects_noir-protocol-circuits_crates_blob	3 s	2 s	1.50
test_report_AztecProtocol_aztec-packages_noir-projects_noir-protocol-circuits_crates_private-kernel-lib	2 s	1 s	2
test_report_AztecProtocol_aztec-packages_noir-projects_noir-protocol-circuits_crates_rollup-lib	4 s	3 s	1.33
test_report_zkpassport_noir-ecdsa_	2 s	1 s	2

This comment was automatically generated by workflow using github-action-benchmark.

CC: @TomAFrench

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Execution Time'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: 1e0d05a	Previous: 80b04ec	Ratio
private-kernel-inner	0.018 s	0.014 s	1.29

This comment was automatically generated by workflow using github-action-benchmark.

CC: @TomAFrench

[TomAFrench]

LGTM