feat: add pass which inlines constant arguments into brillig functions

[asterite]

Description

Problem

Resolves #6812

Summary

Pending:

• Check what happens if the brillig call is recursive
• Determine if the >= 30% heuristic is good
• Determine if the existing optimizations to the new function are good or we need more/others (I copied those from the preprocess pass)
• Add more tests
• Code cleanup

Additional Context

Also includes a commit to get better feedback on SSA test failures, and fixing some indentation in tests.

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 Brillig bytecode sizes

Generated at commit: e8f4741c6c9d5774bd4e1bd5fd54a7a69385892a, compared to commit: 3239a4a79ca1ec2b976da2ca47944cfa9a839c59

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
reference_counts_inliner_max	+11 ❌	+1.23%
reference_counts_inliner_zero	+8 ❌	+0.76%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
reference_counts_inliner_max	903 (+11)	+1.23%
reference_counts_inliner_zero	1,067 (+8)	+0.76%
reference_counts_inliner_min	1,157 (+8)	+0.70%

[github-actions]

Changes to number of Brillig opcodes executed

Generated at commit: e8f4741c6c9d5774bd4e1bd5fd54a7a69385892a, compared to commit: 3239a4a79ca1ec2b976da2ca47944cfa9a839c59

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
reference_counts_inliner_max	+11 ❌	+1.40%
reference_counts_inliner_zero	+11 ❌	+0.72%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
reference_counts_inliner_max	797 (+11)	+1.40%
reference_counts_inliner_zero	1,546 (+11)	+0.72%
reference_counts_inliner_min	1,658 (+11)	+0.67%

[github-actions]

Changes to circuit sizes

Generated at commit: e8f4741c6c9d5774bd4e1bd5fd54a7a69385892a, compared to commit: 3239a4a79ca1ec2b976da2ca47944cfa9a839c59

🧾 Summary (10% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
6	+127 ❌	+57.99%	+4,030 ❌	+56.86%
conditional_regression_short_circuit	+127 ❌	+53.36%	+4,031 ❌	+56.73%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
6	346 (+127)	+57.99%	11,118 (+4,030)	+56.86%
conditional_regression_short_circuit	365 (+127)	+53.36%	11,137 (+4,031)	+56.73%
reference_counts	13 (+5)	+62.50%	21 (+5)	+31.25%
sha256	1,436 (+157)	+12.28%	24,583 (+4,019)	+19.54%
global_var_regression_simple	127 (+61)	+92.42%	3,066 (+152)	+5.22%
sha256_var_padding_regression	3,573 (+105)	+3.03%	166,201 (+3,965)	+2.44%

[github-actions]

⚠️ Performance Alert ⚠️

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

Benchmark suite	Current: 4c8c93d	Previous: 3239a4a	Ratio
rollup-block-root	7870 MB	1420 MB	5.54

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

CC: @TomAFrench

[asterite]

I don't understand why these regressions are happening (and less why the "stack too deep" error happens). I'm looking at the final SSA before and after this PR, and the new SSA is shorter. In the case of program "6" the main function is exactly the same, except that some calls have less arguments because they have been inlined. nargo info tells me it's more ACIR opcodes with this PR, but it's less brillig opcodes, but that's somehow not reflected in the reports. With --profile-execution the executed brillig opcodes are the same, though.

[asterite]

I'm also trying it with this program:

use bignum::BigNum;
use bignum::BigNumTrait;
use bignum::fields::U256::U256Params;

// Define (compile-time) BigNum type
// number of limbs, number of bits of modulus, parameter set
type U256 = BigNum<3, 257, U256Params>;

fn main(x: [Field; 3], y: [Field; 3]) -> pub [Field; 3] {
    let one = U256::from_slice(x);
    let two = U256::from_slice(y);
    // (one + two).limbs
    (one + two).limbs
}

This is the output of nargo info in master:

+---------+------------------+----------------------+--------------+-----------------+
| Package | Function         | Expression Width     | ACIR Opcodes | Brillig Opcodes |
+---------+------------------+----------------------+--------------+-----------------+
| one     | main             | Bounded { width: 4 } | 17           | 783             |
+---------+------------------+----------------------+--------------+-----------------+
| one     | __add_with_flags | N/A                  | N/A          | 783             |
+---------+------------------+----------------------+--------------+-----------------+

(with --profile-execution)

+---------+----------+----------------------+--------------+-----------------+
| Package | Function | Expression Width     | ACIR Opcodes | Brillig Opcodes |
+---------+----------+----------------------+--------------+-----------------+
| one     | main     | Bounded { width: 4 } | 0            | 1617            |
+---------+----------+----------------------+--------------+-----------------+
| one     | main     | N/A                  | N/A          | 1617            |
+---------+----------+----------------------+--------------+-----------------+

And this is the output with this PR:

+---------+------------------+----------------------+--------------+-----------------+
| Package | Function         | Expression Width     | ACIR Opcodes | Brillig Opcodes |
+---------+------------------+----------------------+--------------+-----------------+
| one     | main             | Bounded { width: 4 } | 17           | 719             |
+---------+------------------+----------------------+--------------+-----------------+
| one     | __add_with_flags | N/A                  | N/A          | 719             |
+---------+------------------+----------------------+--------------+-----------------+

(with --profile-execution)

+---------+----------+----------------------+--------------+-----------------+
| Package | Function | Expression Width     | ACIR Opcodes | Brillig Opcodes |
+---------+----------+----------------------+--------------+-----------------+
| one     | main     | Bounded { width: 4 } | 0            | 1617            |
+---------+----------+----------------------+--------------+-----------------+
| one     | main     | N/A                  | N/A          | 1617            |
+---------+----------+----------------------+--------------+-----------------+

So it seems the number of brillig opcodes decreases, but the same number of opcodes is executed.

Maybe we are missing some optimizations done on the functions where constants have been inlined (for example there's no constant folding happening there, though I tried it and it didn't change anything...)