feat: simplify vector_push_back when length is known for complex types

[asterite]

Description

Problem

Extracted from #11659 (more or less)

Summary

The compiler simplifies vector_push_back made with a known length where the value to push to is a make_array. However, this optimization was only done when the vector had single elements, not complex ones. The reason was that there was a check to disable an optimization that later comes on (simplify_vector_push_back), which currently doesn't work for the complex case. However, this check was also disabling the simpler optimization we could do that relies on make_array.

In reality we also needed to change the "known length matches the length of the make_array elements" to consider the semi-flattened length for this case to work.

Additional Context

User Documentation

Check one:

• No user documentation needed.
• Changes in docs/ included in this PR.
• [For Experimental Features] Changes in docs/ 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: f695a587cc6f886972ec89da04e16cf7fc2a8388, compared to commit: 9350cfb4d0a3b16bcf60f74dadcb905df4fa3bfb

🧾 Summary (10% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
nested_array_in_vector	-142 ✅	-16.36%	-562 ✅	-10.51%
vectors	-154 ✅	-47.38%	-680 ✅	-17.28%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
regression_10170	166 (-12)	-6.74%	3,419 (-13)	-0.38%
nested_vector_pop_back	7 (-46)	-86.79%	2,808 (-183)	-6.12%
nested_array_in_vector	726 (-142)	-16.36%	4,784 (-562)	-10.51%
vectors	171 (-154)	-47.38%	3,256 (-680)	-17.28%

[github-actions]

Changes to Brillig bytecode sizes

Generated at commit: f695a587cc6f886972ec89da04e16cf7fc2a8388, compared to commit: 9350cfb4d0a3b16bcf60f74dadcb905df4fa3bfb

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
nested_vector_pop_back_inliner_max	-245 ✅	-75.85%
nested_vector_pop_back_inliner_min	-245 ✅	-75.85%
nested_vector_pop_back_inliner_zero	-245 ✅	-75.85%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
regression_10170_inliner_max	526 (+16)	+3.14%
regression_10170_inliner_min	526 (+16)	+3.14%
regression_10170_inliner_zero	526 (+16)	+3.14%
vector_dynamic_index_inliner_min	2,007 (-6)	-0.30%
vector_dynamic_index_inliner_max	1,693 (-12)	-0.70%
vector_dynamic_index_inliner_zero	1,693 (-12)	-0.70%
array_to_vector_inliner_min	680 (-36)	-5.03%
nested_array_in_vector_inliner_max	745 (-84)	-10.13%
nested_array_in_vector_inliner_min	754 (-105)	-12.22%
nested_array_in_vector_inliner_zero	754 (-105)	-12.22%
vectors_inliner_min	1,951 (-386)	-16.52%
conditional_vector_insert_at_end_of_vector_inliner_max	227 (-61)	-21.18%
conditional_vector_insert_at_end_of_vector_inliner_min	227 (-61)	-21.18%
conditional_vector_insert_at_end_of_vector_inliner_zero	227 (-61)	-21.18%
vectors_inliner_max	1,486 (-474)	-24.18%
vectors_inliner_zero	1,367 (-492)	-26.47%
nested_vector_pop_back_inliner_max	78 (-245)	-75.85%
nested_vector_pop_back_inliner_min	78 (-245)	-75.85%
nested_vector_pop_back_inliner_zero	78 (-245)	-75.85%

[github-actions]

Changes to number of Brillig opcodes executed

Generated at commit: f695a587cc6f886972ec89da04e16cf7fc2a8388, compared to commit: 9350cfb4d0a3b16bcf60f74dadcb905df4fa3bfb

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
nested_vector_pop_back_inliner_max	-213 ✅	-70.30%
nested_vector_pop_back_inliner_min	-213 ✅	-70.30%
nested_vector_pop_back_inliner_zero	-213 ✅	-70.30%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
regression_10170_inliner_max	828 (+9)	+1.10%
regression_10170_inliner_min	828 (+9)	+1.10%
regression_10170_inliner_zero	828 (+9)	+1.10%
vector_dynamic_index_inliner_min	3,458 (-6)	-0.17%
vector_dynamic_index_inliner_max	3,180 (-6)	-0.19%
vector_dynamic_index_inliner_zero	3,180 (-6)	-0.19%
array_to_vector_inliner_min	1,223 (-36)	-2.86%
conditional_vector_insert_at_end_of_vector_inliner_max	295 (-43)	-12.72%
conditional_vector_insert_at_end_of_vector_inliner_min	295 (-43)	-12.72%
conditional_vector_insert_at_end_of_vector_inliner_zero	295 (-43)	-12.72%
nested_array_in_vector_inliner_max	607 (-134)	-18.08%
nested_array_in_vector_inliner_min	616 (-155)	-20.10%
nested_array_in_vector_inliner_zero	616 (-155)	-20.10%
vectors_inliner_min	2,948 (-887)	-23.13%
vectors_inliner_zero	1,877 (-1,005)	-34.87%
vectors_inliner_max	1,711 (-987)	-36.58%
nested_vector_pop_back_inliner_max	90 (-213)	-70.30%
nested_vector_pop_back_inliner_min	90 (-213)	-70.30%
nested_vector_pop_back_inliner_zero	90 (-213)	-70.30%

[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: 25b0587	Previous: 9f2785b	Ratio
rollup-checkpoint-merge	0.003 s	0.002 s	1.50

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

CC: @TomAFrench

[asterite]

This is the only regression. It seems it happens because the optimization kicks in and ends up generating a make_array, but both this new array and the old ones are used. In the old code it was still a vector_push_back which in this particular case ends up being more efficient.

That said, maybe in general this optimization is better than worse.

[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: fc64662	Previous: 00a4db9	Ratio
test_report_zkpassport_noir-ecdsa_	2 s	1 s	2

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

CC: @TomAFrench

[TomAFrench]

How does this handle predicated push_backs?

[asterite]

I think there's no need to look at the predicate because in SSA a vector_push_back returns a copy of the input vector with the added element. Also, this optimization was already happening for vectors with simple elements, now it's also happening for complex elements.

(though I understand where the concern is coming from and I'm also trying to always remember the predicate when doing these optimizations)

[github-actions]

⚠️ Performance Alert ⚠️

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

Benchmark suite	Current: fc64662	Previous: 00a4db9	Ratio
rollup-tx-merge	0.002 s	0.001 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 'Brillig Compilation Time'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: fc64662	Previous: 9f2785b	Ratio
rollup-tx-base-private	2.192 s	1.812 s	1.21

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

CC: @TomAFrench

[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: fc64662	Previous: 9f2785b	Ratio
rollup-tx-base-private	23.02 s	17.8 s	1.29

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

CC: @TomAFrench

[aakoshh]

Looks good!

I am trying another experiment on top of this to see what happens if we try to remove the ValueMerger from the simplify_vector_push_back method, as it seems to me that set_last_vector is already the content that we want. Having some trouble with it, but if it works, I'll open that as a follow up.

[TomAFrench]

Happy to merge and we can merge the followup into master after but will leave up to @aakoshh