chore: greenglight remove_ureachable_instructions

[asterite]

Description

Problem

Resolves #9518

Summary

This just add docs.

I documented how it works but I'm not sure why:

• for array operations we don't put a constrain failure instead of creating a dummy array and fetching from it
• for slice operations we create a zeroed slice and return it when we already have a guaranteed empty slice (the one that produces the failure) so we could continue with that slice instead of create a new, empty one

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.

[github-actions]

⚠️ Performance Alert ⚠️

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

Benchmark suite	Current: 8f1d9ce	Previous: e5bd638	Ratio
rollup-block-root-empty	30.58 s	21.84 s	1.40

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

CC: @TomAFrench

[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: b5eb4d7	Previous: 19f2525	Ratio
test_report_noir-lang_noir_bigcurve_	393 s	326 s	1.21

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

CC: @TomAFrench

[vezenovm]

• for array operations we don't put a constrain failure instead of creating a dummy array and fetching from it

This is because we gate the check only for ACIR. ACIR array operations are side effectual and check for array OOBs, while in Brillig they do not so we would have to insert a constrain in the Brillig runtime #9378. However, this was breaking due to #7289 still being open at the time. I want to hold off on merging #9378 though as it looks like we are getting failures in aztec-packages from #9412 still.

• for slice operations we create a zeroed slice and return it when we already have a guaranteed empty slice (the one that produces the failure) so we could continue with that slice instead of create a new, empty one

This is a good point. We could change this logic and slightly simplify that case.

[asterite]

This is a good point. We could change this logic and slightly simplify that case.

In the end I'm not sure this is worth it. The slice operations return the slice but also the popped element so we'd have to zero that anyway.

[vezenovm]

The slice operations return the slice but also the popped element so we'd have to zero that anyway.

We could just add that as an inline comment as an extra justification.

[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: d609445	Previous: 23ba35f	Ratio
rollup-root	0.005 s	0.004 s	1.25

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

CC: @TomAFrench