fix: set index and value to 0 for array_get with predicate

[guipublic]

Description

Problem*

Resolves issue on noir-protocol-circuit and should also resolve issues described in #4716.
The issue it resolves is that array_get under a predicate are done at index 0 if the predicate is false, but since arrays are not homogenous, it may contain some value that overflow the type of the array_get.

Summary*

When getting value from an array_get, I multiply it with the predicate to avoid any possible overflow if element at index 0 has not the same type as the expected one.

Additional Context

If the array is simple (not nested), I get the offset to a compatible type and use it when computing the predicate_index.
If the first element of the array has compatible size, then the predicate_index will be correct
If not, we fallback to the multiplication of the value with the predicate.

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: fe174de19d37d04f7dbc98ab69147770c5982c21, compared to commit: f3f11507983009771656811f9570bdbe6849c7ef

🧾 Summary (10% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
hashmap	+926 ❌	+0.53%	+926 ❌	+0.25%
slices	+1 ❌	+0.29%	+1 ❌	+0.03%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
hashmap	176,988 (+926)	+0.53%	368,860 (+926)	+0.25%
slices	351 (+1)	+0.29%	3,421 (+1)	+0.03%
slice_dynamic_index	1,355 (+2)	+0.15%	6,949 (+2)	+0.03%
nested_array_dynamic	4,585 (+1)	+0.02%	12,952 (+1)	+0.01%

[TomAFrench]

It would be interesting to compare this against the solution of adding an index offset instead of reading 0 to ensure that we read the correct typed value from the array. This keeps the final value a single witness rather than a quadratic expression so should result in better codegen in later opcodes.

[TomAFrench]

The above comment isn't a blocker for this PR and I've opened #4972 to follow up on this.

[TomAFrench]

It also seems like we can be smarter about when to multiply in the predicate/add an offset to the index. We only need to do this when the type which we would read is larger than the type we want to read. We can then avoid this in two cases.

1. The array is homogeneous (I think this would cut out 99% of the circuit size increase we see)
2. The array is heterogeneous but the type of the first field of the element type is smaller than the type we want to read. i.e. [Struct {foo: bool, bar: Field}; 3] can always read the first field in the flattened array safely and use its value for all other indices.

[guipublic]

It also seems like we can be smarter about when to multiply in the predicate/add an offset to the index. We only need to do this when the type which we would read is larger than the type we want to read.

Good point, I have also added the use of the offset when the array is not a nested array. So the rule now is:

• if array is not nested, find the offset and use it for the predicate_index, else
• if the first element of the array has compatible bit_size, we can use directly the predicate_index, else
• fallback to the multiply the value with the predicate.

I have updated the PR description.
I could not get the offset to work with nested arrays but it is definitively do-able. However, almost all cases are now properly optimised.

[TomAFrench]

Some nits but good to go.