chore: Add Instruction::DecrementRc

[jfecher]

Description

Problem*

Resolves #4522

Summary*

Experimenting with this to see how much it improves performance of unconstrained code using arrays.

Additional Context

Currently the new dec_rc instruction is only issued for function parameters when a function is finished - assuming the parameters are not also returned.

CC @sirasistant for visibility

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [Exceptional Case] 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 circuit sizes

Generated at commit: 17a1d9d2094f462dff330f97412a3445a90fb13d, compared to commit: 44e60b67469de88f20842c4eead64d736f7bd4a0

🧾 Summary (10% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
hashmap	-338 ✅	-0.15%	-338 ✅	-0.07%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
hashmap	219,271 (-338)	-0.15%	491,765 (-338)	-0.07%

[jfecher]

This seems to be a considerable improvement for pathological cases at least. Here's an example:

unconstrained fn main() {
    let mut array = [0; 10000];

    for i in 0 .. array.len() {
        array[i] = i;

        // This increments the reference count of `array` on each iteration,
        // tanking performance even though the `array2` parameter of `foo`:
        // 1. is not returned, so its lifetime should not prevent the mutation of `array`
        // 2. is not itself mutable
        foo(array);
    }
}

unconstrained fn foo<N>(_array2: [u64; N]) {}

On master this runs in 5m 50s on my desktop.
On this branch, this runs in 0.67s

[jfecher]

Not sure why the brillig_assert_msg_runtime test is incorrectly passing now.
I suppose the inputs are getting mangled somehow since v73 = eq v0, Field 10 passes but v0 is x and x = 5 in the Prover.toml.
Either that or this is skipped entirely somehow.

[sirasistant]

Not sure why the brillig_assert_msg_runtime test is incorrectly passing now.
I suppose the inputs are getting mangled somehow since v73 = eq v0, Field 10 passes but v0 is x and x = 5 in the Prover.toml.
Either that or this is skipped entirely somehow.

Fixed it here #4531

[sirasistant]

Let's see if we get some nice speedups!

[jfecher]

Removing this from the queue to investigate why poseidonsponge_x5_254 blew up in size

[jfecher]

I'm still unable to find why poseidonsponge_x5_254 has bloated so much. Oddly enough, the SSA is actually shorter for the version on this branch than in master.

The most I've confirmed so far is that it is due to the new DecrementRc instructions rather than the changed location of the IncrementRc instructions from call arguments to function parameters. I'm not sure why this is though, given both of these are ignored in acir-gen and this test only uses acir functions.

[jfecher]

Found the culprit with @vezenovm's help. IncRc was special cased in the DIE pass but dec rc was not. This lead to dec_rc's values getting counted as used and they weren't eliminated from the program as a result.

[vezenovm]

hashmap -338 ✅ -0.15% -338 ✅ -0.07%

Now we actually have an improvement in one case :D