feat(optimization): Add purity analysis to SSA

[jfecher]

Description

Problem*

Resolves #7196

Summary*

Adds a purity analysis pass to approximate the purity of each function (we only fail for mutually recursive functions) and use its results in other SSA passes.

Additional Context

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 number of Brillig opcodes executed

Generated at commit: 51c80bdb74856a00c6368d9fa46902cb63949ce4, compared to commit: 2d2c73b462abdf1c1bcbe35cac6f48bd685dbbce

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
conditional_regression_short_circuit_inliner_min	-3,793 ✅	-43.32%
6_inliner_min	-3,793 ✅	-43.85%
binary_operator_overloading_inliner_zero	-236 ✅	-50.64%
fold_basic_inliner_min	-40 ✅	-51.28%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
poseidon2_inliner_min	873 (+1)	+0.11%
regression_5252_inliner_min	1,031,270 (+2)	+0.00%
uhashmap_inliner_min	196,981 (-180)	-0.09%
hashmap_inliner_min	90,362 (-179)	-0.20%
global_var_regression_entry_points_inliner_min	135,432 (-288)	-0.21%
global_var_regression_entry_points_inliner_zero	135,311 (-336)	-0.25%
higher_order_functions_inliner_min	2,273 (-18)	-0.79%
hashmap_inliner_zero	74,602 (-626)	-0.83%
7_function_inliner_zero	2,439 (-35)	-1.41%
slices_inliner_zero	3,594 (-70)	-1.91%
u128_inliner_min	48,483 (-3,734)	-7.15%
u128_inliner_zero	40,944 (-3,510)	-7.90%
aes128_encrypt_inliner_zero	3,075 (-364)	-10.58%
6_array_inliner_min	2,540 (-350)	-12.11%
6_array_inliner_zero	2,470 (-350)	-12.41%
sha256_var_padding_regression_inliner_min	231,918 (-35,338)	-13.22%
sha256_var_padding_regression_inliner_zero	230,407 (-35,186)	-13.25%
sha256_inliner_min	12,303 (-4,253)	-25.69%
sha256_inliner_zero	11,358 (-3,938)	-25.75%
brillig_nested_arrays_inliner_zero	301 (-145)	-32.51%
brillig_cow_inliner_zero	803 (-399)	-33.19%
binary_operator_overloading_inliner_min	402 (-236)	-36.99%
u16_support_inliner_min	51 (-31)	-37.80%
u16_support_inliner_zero	51 (-31)	-37.80%
fold_basic_nested_call_inliner_min	54 (-36)	-40.00%
conditional_regression_short_circuit_inliner_zero	4,520 (-3,392)	-42.87%
6_inliner_zero	4,440 (-3,392)	-43.31%
conditional_regression_short_circuit_inliner_min	4,962 (-3,793)	-43.32%
6_inliner_min	4,856 (-3,793)	-43.85%
binary_operator_overloading_inliner_zero	230 (-236)	-50.64%
fold_basic_inliner_min	38 (-40)	-51.28%

[github-actions]

Changes to circuit sizes

Generated at commit: 51c80bdb74856a00c6368d9fa46902cb63949ce4, compared to commit: 2d2c73b462abdf1c1bcbe35cac6f48bd685dbbce

🧾 Summary (10% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
conditional_regression_short_circuit	-127 ✅	-34.79%	-4,031 ✅	-36.19%
6	-127 ✅	-36.71%	-4,030 ✅	-36.25%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
pedersen_check	15 (-4)	-21.05%	3,170 (-2)	-0.06%
global_var_regression_simple	66 (-61)	-48.03%	2,914 (-152)	-4.96%
fold_call_witness_condition	4 (-1)	-20.00%	18 (-1)	-5.26%
fold_basic	1 (-4)	-80.00%	16 (-1)	-5.88%
fold_basic_nested_call	1 (-2)	-66.67%	16 (-1)	-5.88%
sha256_var_padding_regression	3,468 (-350)	-9.17%	162,236 (-31,417)	-16.22%
sha256	1,279 (-157)	-10.93%	20,564 (-4,019)	-16.35%
global_var_regression_entry_points	6 (-20)	-76.92%	18 (-10)	-35.71%
conditional_regression_short_circuit	238 (-127)	-34.79%	7,106 (-4,031)	-36.19%
6	219 (-127)	-36.71%	7,088 (-4,030)	-36.25%

[jfecher]

Pending some tests but the pass itself is finished

[jfecher]

Moved the purity pass, and added another closer to the end of SSA.
I've found the results can change as different calls get optimized out so I opted to move the call closer to:

1. The loop invariant code motion pass
2. The constant folding pass

[jfecher]

This PR still doesn't seem to be deduplicating

fn main(x: Field) {
    unsafe {
        let x1 = foo(x);
        let x2 = foo(x);
        assert_eq(x1, 0);
        assert_eq(x2, 0);
    }
}

unconstrained fn foo(x: Field) -> Field {
    x
}

[TomAFrench]

We don't currently do any deduplication of brillig calls so I think we should add a test to ensure that we don't end up deduplicating a brillig call such that an incorrect predicate is applied.

e.g. something like the below (I haven't check that DIE doesn't ruin this example)

fn main(x: Field, active: bool) {
    let mut x1 = false;
    unsafe {
        if active {
            x1 = foo(x);        
        }
    
        let x2 = foo(x);
        assert_eq(x2);
    }
}

unconstrained fn foo(x: Field) -> bool {
    true
}

[jfecher]

@TomAFrench That should be prevented by the existing dominates check when deduplicating (edit: I'm wrong, it is at first but not after flattening of course). Code like that should be fine for hoisting though (right? Unless we return zeroed/bogus values in that case which would complicate things). We do complicate things... so brillig functions can never be pure then, they're pure with predicate at minimum... but only when called from acir 😮‍💨

There are three types of Purity in this PR:

• Pure: Function is really pure & we can move it anywhere without noticeable change. This applies to foo in your example.
• PureWithPredicate: function isn't really pure but if it has the same predicate as another identical call then we can deduplicate it to avoid repeating work. This applies to functions with constraints in them.
• Impure: Can't move or deduplicate even with identical arguments & predicate

[jfecher]

I've also found the reason we weren't deduplicating was that we've been introducing different ValueIds for the same function:

acir(inline) predicate_pure fn main f0 {
  b0(v0: Field):
    v2 = call (v1) f1(v0) -> Field
    v4 = call (v3) f1(v0) -> Field
    constrain v2 == Field 0
    constrain v4 == Field 0
    return
}

Edit: Oh my god, we were never storing to self.functions in dfg::import_function 🤦‍♂️. We were just always creating a new ValueId for who knows how long.

[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: d204f44	Previous: dc06d8e	Ratio
sha256_regression	3.09 s	1.16 s	2.66
regression_4709	7.41 s	0.828 s	8.95
ram_blowup_regression	31.3 s	18.8 s	1.66
rollup-root	6.01 s	3.504 s	1.72
rollup-merge	2.65 s	2.004 s	1.32
rollup-block-root-single-tx	269 s	85.6 s	3.14
rollup-block-root-empty	2.842 s	2.014 s	1.41
rollup-block-root	274 s	87 s	3.15
rollup-block-merge	5.942 s	3.47 s	1.71
rollup-base-public	91.64 s	34.06 s	2.69
rollup-base-private	35.5 s	12.74 s	2.79
private-kernel-inner	5.608 s	2.098 s	2.67

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

CC: @TomAFrench

[github-actions]

Changes to Brillig bytecode sizes

Generated at commit: 51c80bdb74856a00c6368d9fa46902cb63949ce4, compared to commit: 2d2c73b462abdf1c1bcbe35cac6f48bd685dbbce

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
fold_basic_nested_call_inliner_min	-12 ✅	-19.35%
binary_operator_overloading_inliner_min	-90 ✅	-20.09%
binary_operator_overloading_inliner_zero	-90 ✅	-28.30%
fold_basic_inliner_min	-24 ✅	-38.71%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
poseidon2_inliner_min	378 (+1)	+0.27%
regression_5252_inliner_min	3,571 (+1)	+0.03%
global_var_regression_entry_points_inliner_min	133,784 (-80)	-0.06%
global_var_regression_entry_points_inliner_zero	133,757 (-87)	-0.07%
hashmap_inliner_min	9,791 (-13)	-0.13%
uhashmap_inliner_min	8,330 (-26)	-0.31%
slices_inliner_zero	2,084 (-9)	-0.43%
sha256_var_padding_regression_inliner_zero	2,928 (-19)	-0.64%
sha256_var_padding_regression_inliner_min	3,216 (-22)	-0.68%
hashmap_inliner_zero	7,835 (-54)	-0.68%
conditional_regression_short_circuit_inliner_min	1,117 (-8)	-0.71%
6_inliner_min	1,016 (-8)	-0.78%
conditional_regression_short_circuit_inliner_zero	917 (-8)	-0.86%
higher_order_functions_inliner_min	1,337 (-12)	-0.89%
6_inliner_zero	835 (-8)	-0.95%
sha256_inliner_min	1,395 (-19)	-1.34%
u128_inliner_min	2,263 (-32)	-1.39%
sha256_inliner_zero	1,234 (-19)	-1.52%
u128_inliner_zero	1,957 (-32)	-1.61%
7_function_inliner_zero	518 (-14)	-2.63%
aes128_encrypt_inliner_zero	388 (-11)	-2.76%
6_array_inliner_min	446 (-16)	-3.46%
6_array_inliner_zero	436 (-16)	-3.54%
brillig_nested_arrays_inliner_zero	241 (-19)	-7.31%
u16_support_inliner_min	59 (-6)	-9.23%
u16_support_inliner_zero	59 (-6)	-9.23%
brillig_cow_inliner_zero	239 (-33)	-12.13%
fold_basic_nested_call_inliner_min	50 (-12)	-19.35%
binary_operator_overloading_inliner_min	358 (-90)	-20.09%
binary_operator_overloading_inliner_zero	228 (-90)	-28.30%
fold_basic_inliner_min	38 (-24)	-38.71%

[jfecher]

I think the performance alert here may be bugged. I tested sha256_regression locally and found that this PR compiles it slightly faster, not several times slower. I also opened #7227 to run the CI on a fresh PR and it shows no performance regression comment there.

[TomAFrench]

I think the performance alert here may be bugged. I tested sha256_regression locally and found that this PR compiles it slightly faster, not several times slower.

One thing to note is that the new action doesn't replace old alerts as you push new commits to a PR so the one in this branch is working off of d204f44 whereas #7227 is running off of 668a543.

Pulling out the rollup-base-public circuit we can see that it takes 2m6s to compile as of d204f44:
https://github.com/noir-lang/noir/actions/runs/13019154003/job/36315710426

whereas on 668a543 it takes just 1m15s
https://github.com/noir-lang/noir/actions/runs/13037349787/job/36371109161

[TomAFrench]

I think it's basically correct but not the best at flagging that a regression has been resolved.

[jfecher]

Since there are no perf regressions this is ready to review again at least

[TomAFrench]

LGTM. Only followup improvement (which I expect won't catch much that this PR doesn't catch already)