fix(ssa_interpreter): push_back and pop_back to slices with padding

[aakoshh]

Description

Problem*

Resolves #9312

Summary*

Change slice_push_back and slice_push_front to take into account any potential extra items in the slice which are beyond its length. Push and pop must operate before this region. This is achieved by removing any potential extras, since they are never accessed by the interpreter.

Additional Context

This situation arises when we have something like this code:

let a: [u32] = [1, 2];
let b: [u32] = [3, 4, 5, 6]; 
let c: [u32] = if p { a } else { b };
let (d, e) = c.pop_back();
let f = c.push_back(7);

The SSA pass that removes the IfElse expressions creates a slice like this:

c_len = p * 2 + (1 - p) * 4
c_data = [p * a[0] + (1-p) * b[0], p * a[1] + (1-p) * b[1], b[2], b[3]]

If p is true, c ends up looking like [1,2,5,6], and after pushing we want it to be (3, [1,2,7,5,6]), or if we pop then it should return (1, [1,5,6], 2) (length, data, elem).

Initially I appended the extra items back onto the slice, but recognised some alternatives:

• We could drop the extras; at least I can't think of a situation outside of printing where they would come into play.
• We could overwrite the extras in push_back, rather than grow the slice, to reclaim space; not like the interpreter is necessarily built to be efficient, just to maybe match what ACIR or Brillig might do.

I checked what ACIR passes to the print oracle after a push/pop, but it doesn't looks like something the interpreter aims to match:

fn main(a: bool) {
    let s0: [u32] = if a { &[10, 20] } else { &[30, 40, 50] };
    println(s0);
    let (s1, _) = s0.pop_back();
    println(s1);
    let s2 = s0.push_back(60);
    println(s2);
}

The values passed to the foreign function look like this:

args[0] = Single(2)
args[1] = Array([10, 20, 0])
&[10, 20]
args[0] = Single(1)
args[1] = Array([10, 20, 0])
&[10]
args[0] = Single(3)
args[1] = Array([10, 20, 60, 60])
&[10, 20, 60]

So popping didn't make the array shorter, just decreased the length, and pushing both filled the extra element and added a new one.

For this reason I concluded that the extra elements shouldn't be relied on to have any particular content, and it's best if we truncate the slices in the interpreter during pushing and popping, rather than go the extra mile to keep the extra elements. I didn't update other slice operations though.

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: 2302d21	Previous: 42429ab	Ratio
sha512-100-bytes	1.969 s	1.592 s	1.24

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: 2302d21	Previous: 42429ab	Ratio
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	2 s	2
test_report_AztecProtocol_aztec-packages_noir-projects_noir-protocol-circuits_crates_types	2 s	1 s	2
test_report_zkpassport_noir-ecdsa_	2 s	1 s	2

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

CC: @TomAFrench

[jfecher]

and pushing both filled the extra element and added a new one.

I wonder if this could be related to any of the performance issues with slices.

Maybe this could happen if e.g. you have a if foo { slice = slice.push_back(..) } which causes us to merge a slice of length N with one of length N + 1, so you'd get these empty spaces pushed every loop effectively and not used by the next push back.