fix(ssa): Remove array from cache in constant folding if it's an argument to a Call

[aakoshh]

Description

Problem*

Resolves #9037

Summary*

Constant folding has a remove_possibly_mutated_cached_make_arrays method to remove MakeArray and Call instructions from the cache used to deduplicate instructions and reuse their results, if the array returned by those instructions is used in a Store or an ArraySet. That is, if we know we write to the array, we don't use it to replace an identical MakeArray call, or if we know that we store it in a reference, we treat it as opaque, like anything can happen to it after.

This PR extends this to arrays passed to other functions as Call arguments. To avoid being too heavy handed, this is only done for Brillig functions, and only if the callee is an impure user function, which should help with e.g. println.

Additional Context

This rule is stricter than necessary. We could make it more permissive by tracking whether the array returned by the previous instructions has a positive reference count in the current block. If it does, then any modifications to it it should modify a copy, leaving the original safe to reuse.

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: 696c3f1b57cfa48eff4cb1511a5896d7938ed4b5, compared to commit: 30a491dc54903658553b32906a9b2a510121a141

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
fold_2_to_17_inliner_zero	+11 ❌	+3.49%
fold_2_to_17_inliner_min	+11 ❌	+3.21%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
fold_2_to_17_inliner_zero	326 (+11)	+3.49%
fold_2_to_17_inliner_min	354 (+11)	+3.21%

[github-actions]

Changes to number of Brillig opcodes executed

Generated at commit: 696c3f1b57cfa48eff4cb1511a5896d7938ed4b5, compared to commit: 30a491dc54903658553b32906a9b2a510121a141

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
fold_2_to_17_inliner_zero	+27,968 ❌	+2.69%
fold_2_to_17_inliner_min	+27,968 ❌	+2.69%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
fold_2_to_17_inliner_zero	1,068,991 (+27,968)	+2.69%
fold_2_to_17_inliner_min	1,069,063 (+27,968)	+2.69%

[jfecher]

Looks good. I was worried about only checking this for brillig functions at first but remembered that we only mutate arrays or do inc_rc at all in brillig anyway.

Getting an odd type error in CI

[aakoshh]

The type error seems to be nargo expand not rendering ([false], ) back as tuple, but rather just ([false])

thread 'tests::nargo_expand_execution_success::test_regression_9037' panicked at /home/runner/.rustup/toolchains/1.85.0-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5:
Unexpected failure.
code=1
stderr=``````
error: Expected type ([bool; 1],), found type [bool; 1]
  ┌─ /tmp/.tmp76O4Rd/src/main.nr:1:28
  │
1 │ global G_B: ([bool; 1],) = ([false]);
  │                            ---------
  │

Aborting due to 1 previous error

@asterite

I'll change it here to add some dummy second element.

[asterite]

@aakoshh Mind if I fix that nargo expand issue in this PR? Here's the diff to fix it:

diff --git a/tooling/nargo_expand/src/printer.rs b/tooling/nargo_expand/src/printer.rs
index 18d9d111b0..33d3db47a1 100644
--- a/tooling/nargo_expand/src/printer.rs
+++ b/tooling/nargo_expand/src/printer.rs
@@ -807,6 +807,9 @@ impl<'context, 'string> ItemPrinter<'context, 'string> {
                     }
                     self.show_value(value);
                 }
+                if values.len() == 1 {
+                    self.push(',');
+                }
                 self.push(')');
             }
             Value::Struct(fields, typ) => {

[jfecher]

Pulled this from the merge queue in case you wanted to apply the nargo expand patch