fix(ssa): Handle partially removed ArrayGet groups of complex type during OOB checks

[aakoshh]

Description

Problem*

Resolves #9851
Resolves #9852
Resolves #9873

Summary*

Fixes handle_array_get_group to not assume that all array_get and add pairs will be there.

The new detection mechanism is basically to loop through the next instructions and check that they are either an add, or an array_get from the same array with an unsafe index. If either of those condition do not hold, then we conclude that the unsafe&unused instruction we are currently on is the last of the group. Then, we check how many array_get we encountered in the group and how many of those were also found in the possible_index_out_of_bounds_indexes collection, which indicates they were also unused. If the two matches, then a constraint will be included.

This means something like array_get v1, u32 10000000; array_get v1, u32 0; array_get v1, u32 100000001 will have a constraint inserted after the 1st and 3rd array_get separately, as they are treated as different groups, even though they are on the same array, because in between them is a safe access. Such code will not be generated by the initial SSA, but ostensibly they could be a result of an earlier DIE pass having removed and merged 3 different groups.

Additional Context

In the example I found, the SSA before the first DIE pass (part of Preprocess), was like this:

acir(inline) predicate_pure fn main f0 {
  b0():
    v2 = make_array b"KO"
    v4 = make_array [u1 0, v2] : [(u1, [u8; 2]); 1]
    v6 = array_get v4, index u32 20 -> u1
    v8 = array_get v4, index u32 21 -> [u8; 2]
    v9 = allocate -> &mut u1
    store v6 at v9
    return u1 1
}

So v8 is unused, but v6 is not. This resulted in scenario c) in the handle_array_get_group function, so it let DIE remove the second array_get. Then, mem2reg figured out that we don't need the store v6 at v9 instruction, leaving v6 unused as well, however this time DIE didn't realise that it needs to insert a constraint, because it couldnt' find the entire group.

I did not attempt any refactoring as mentioned in #9890 and #9891 but I agree that it's difficult to follow the index manipulation.

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.

[github-actions]

Changes to circuit sizes

Generated at commit: caf1ea45a03cfb6a2ef22979ca64ee747153c9d1, compared to commit: 42a64e705e7efd4a385f169736a64e37c4ba4e61

🧾 Summary (10% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
lambda_from_array	+32 ❌	+1.77%	+30 ❌	+0.75%
regression_struct_array_conditional	+9 ❌	+11.84%	+9 ❌	+0.28%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
lambda_from_array	1,841 (+32)	+1.77%	4,054 (+30)	+0.75%
regression_struct_array_conditional	85 (+9)	+11.84%	3,221 (+9)	+0.28%
nested_array_dynamic	3,237 (+32)	+1.00%	12,115 (+30)	+0.25%
lambda_from_global_array	30 (+4)	+15.38%	2,802 (+4)	+0.14%
databus_composite_calldata	137 (+4)	+3.01%	3,103 (+4)	+0.13%
array_dynamic_nested_blackbox_input	135 (+4)	+3.05%	17,416 (0)	0.00%

[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: 3bedb8e	Previous: 70cb55c	Ratio
test_report_zkpassport_noir-ecdsa_	3 s	2 s	1.50

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: 0498d74	Previous: 42a64e7	Ratio
sha512-100-bytes	0.095 s	0.056 s	1.70

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

CC: @TomAFrench

[jfecher]

Reasoning makes sense to me