feat(ssa): Basic control dependent LICM

[vezenovm]

Description

Problem*

Resolves #7569

Builds upon #7595 (post-dominator tree) and #7692 (dominance frontiers)

This PR resolves the optimizations described in the issue. However, the optimization can be expanded by further accounting for predicates and possibly even hoisting instructions under predicates as part of loop peeling/splitting. I leave these tasks to be captured in separate issues.

Summary*

We have certain instructions that we mark as unsafe for hoisting when they are only dependent upon a predicate and do not have any other side effects (e.g. a checked arithmetic operation). You can look into the linked issue for an example of logic that will not be hoisted.

If a predicated instruction shares the same predicate as the entire loop we can now hoist this instruction. The new unit tests under loop_invariant.rs provide examples of when a predicated instruction can now be hoisted.

We check for whether an instruction shares a predicate with the entire loop through control dependence analysis. If the block containing an instruction is control dependent on any blocks between the pre-header and the instruction's block we know that there has been some branching. We then mark the current block as being control dependent.

If a block is not control dependent, we mark instructions that are reliant upon predicates (but do not have other side effects) as safe for hoisting.

We determine whether a block is control dependent on a parent block by following Definition 3 in Ferrante et al., 1987, The program dependence graph and its use in optimization.

Definition 3. Let G be a control flow graph. Let X and Y be nodes in G. Y is
control dependent on X iff
(1) there exists a directed path P from X to Y with any 2 in P (excluding X
and Y) post-dominated by Y and
(2) X is not post-dominated by Y. 

Builds upon #7595 to utilize the post-dominator tree. We can further optimize our control dependence check by looking at the post-dominator frontiers #7692.

Verifying the above conditions for every loop block would be quite inefficient.
For example, let's say we just want to check whether a given loop block is control dependent at all
after the loop preheader. We would have to to verify the conditions above for every block between the loop preheader
and the given loop block. This is n^2 complexity in the worst case.

To optimize the control dependence checks, we can use post-dominance frontiers (PDF).
From Cooper, Keith D. et al. “A Simple, Fast Dominance Algorithm.” (1999).

A dominance frontier is the set of all CFG nodes, y, such that
b dominates a predecessor of y but does not strictly dominate y.

Reversing this for post-dominance we can see that the conditions for control dependence
are the same as those for post-dominance frontiers.
Thus, we rewrite our control dependence condition as Y is control dependent on X iff Y is in PDF(Y).
We then can store the PDFs for every block as part of the context of this pass, and use it for checking control dependence.
Using PDFs gets us from a worst case n^2 complexity to a worst case n.

Hoisting vs. Deduplicating

This PR also adds a new method can_be_hoisted on Instruction. This is essentially the same as can_be_deduplicated except it accounts for that certain instructions are not safe for hoisting as lone instructions. The main difference is that we do not hoist Constrain, ConstrainNotEqual, RangeCheck, and functions with Purity::PureWithPredicate with predicates.

The reason for this is that we may have dynamic loop bounds or a equal lower and upper loop bounds (e.g. a loop that will never execute). If we were to hoist the instructions above they could potentially cause a program to fail when it should not. When deduplicating this is allowed as we have a matching instruction, but for hoisting this can break the program logic.

Additional Context

As mentioned in the PR description this work builds upon #7595 and #7692. You may want to review those PRs first as to have the full context. This is also outlined in the new doc comments on the loop invariant pass.

We can probably further differentiate Purity::PureWithPredicate to differentiate between instructions pure with predicates for hoisting and pure with predicates for deduplication. I leave this for follow-up work.

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]

⚠️ 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: 305f5e2	Previous: 58be0cd	Ratio
noir-lang_noir_json_parser_	12 s	8 s	1.50

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

CC: @TomAFrench

[github-actions]

Changes to Brillig bytecode sizes

Generated at commit: 0b9db7264e237efca7a5fd51ad12dd307f6a8b4f, compared to commit: 58be0cd3897cd8ca3a99bac3b9fbbe561dfcb4a8

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
poseidon_bn254_hash_inliner_min	-12 ✅	-0.24%
poseidon_bn254_hash_width_3_inliner_min	-12 ✅	-0.24%
loop_invariant_regression_inliner_max	-16 ✅	-10.67%
loop_invariant_regression_inliner_zero	-16 ✅	-10.67%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
poseidon_bn254_hash_inliner_max	5,242 (-2)	-0.04%
poseidon_bn254_hash_width_3_inliner_max	5,242 (-2)	-0.04%
poseidon_bn254_hash_inliner_zero	4,656 (-2)	-0.04%
poseidon_bn254_hash_width_3_inliner_zero	4,656 (-2)	-0.04%
regression_5252_inliner_max	4,434 (-2)	-0.05%
poseidonsponge_x5_254_inliner_max	4,098 (-2)	-0.05%
regression_5252_inliner_min	3,555 (-6)	-0.17%
regression_5252_inliner_zero	3,390 (-6)	-0.18%
poseidonsponge_x5_254_inliner_min	3,159 (-6)	-0.19%
poseidonsponge_x5_254_inliner_zero	3,019 (-6)	-0.20%
poseidon_bn254_hash_inliner_min	5,023 (-12)	-0.24%
poseidon_bn254_hash_width_3_inliner_min	5,023 (-12)	-0.24%
loop_invariant_regression_inliner_max	134 (-16)	-10.67%
loop_invariant_regression_inliner_zero	134 (-16)	-10.67%

[github-actions]

Compilation Time

Details

Benchmark suite	Current: 305f5e2	Previous: 58be0cd	Ratio
regression_4709	0.708 s	0.67 s	1.06
ram_blowup_regression	14.8 s	14.6 s	1.01
global_var_regression_entry_points	0.498 s	0.484 s	1.03
private-kernel-inner	2.274 s	2.388 s	0.95
private-kernel-reset	6.706 s	6.782 s	0.99
private-kernel-tail	1.088 s	1.104 s	0.99
rollup-base-private	16.42 s	15.2 s	1.08
rollup-base-public	12.76 s	11.34 s	1.13
rollup-block-root-empty	0.973 s	0.933 s	1.04
rollup-block-root-single-tx	130 s	129 s	1.01
rollup-block-root	128 s	133 s	0.96
rollup-merge	0.943 s	0.928 s	1.02
rollup-root	1.478 s	1.57 s	0.94

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

[github-actions]

Execution Time

Details

Benchmark suite	Current: 305f5e2	Previous: 58be0cd	Ratio
private-kernel-inner	0.069 s	0.069 s	1
private-kernel-reset	0.284 s	0.283 s	1.00
private-kernel-tail	0.026 s	0.026 s	1
rollup-base-private	0.728 s	0.73 s	1.00
rollup-base-public	0.488 s	0.487 s	1.00
rollup-block-root	17.1 s	16.7 s	1.02
rollup-merge	0.006 s	0.006 s	1
rollup-root	0.024 s	0.025 s	0.96

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

[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: 60a01ba	Previous: 4c1c76e	Ratio
regression_4709	0.893 s	0.693 s	1.29

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

CC: @TomAFrench

[github-actions]

Test Suite Duration

Details

Benchmark suite	Current: 305f5e2	Previous: 58be0cd	Ratio
AztecProtocol_aztec-packages_noir-projects_aztec-nr	37 s	37 s	1
AztecProtocol_aztec-packages_noir-projects_noir-contracts	77 s	78 s	0.99
AztecProtocol_aztec-packages_noir-projects_noir-protocol-circuits_crates_blob	46 s	44 s	1.05
AztecProtocol_aztec-packages_noir-projects_noir-protocol-circuits_crates_private-kernel-lib	172 s	170 s	1.01
AztecProtocol_aztec-packages_noir-projects_noir-protocol-circuits_crates_reset-kernel-lib	10 s	9 s	1.11
AztecProtocol_aztec-packages_noir-projects_noir-protocol-circuits_crates_rollup-lib	169 s	168 s	1.01
AztecProtocol_aztec-packages_noir-projects_noir-protocol-circuits_crates_types	53 s	54 s	0.98
noir-lang_noir-bignum_	84 s	86 s	0.98
noir-lang_noir_bigcurve_	223 s	209 s	1.07
noir-lang_noir_json_parser_	12 s	8 s	1.50
noir-lang_sha512_	24 s	23 s	1.04

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

[github-actions]

Compilation Memory

Details

Benchmark suite	Current: 305f5e2	Previous: 58be0cd	Ratio
private-kernel-inner	301.59 MB	301.63 MB	1.00
private-kernel-reset	611.54 MB	611.54 MB	1
private-kernel-tail	228.23 MB	228.23 MB	1
rollup-base-private	1250 MB	1250 MB	1
rollup-base-public	1330 MB	1330 MB	1
rollup-block-root-empty	305.09 MB	305.11 MB	1.00
rollup-block-root-single-tx	7860 MB	7860 MB	1
rollup-block-root	7870 MB	7870 MB	1
rollup-merge	303.51 MB	303.53 MB	1.00
rollup-root	351.07 MB	351.05 MB	1.00

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

[github-actions]

Execution Memory

Details

Benchmark suite	Current: 305f5e2	Previous: 58be0cd	Ratio
private-kernel-inner	241.44 MB	241.44 MB	1
private-kernel-reset	275.87 MB	275.87 MB	1
private-kernel-tail	215.09 MB	215.09 MB	1
rollup-base-private	509.27 MB	509.27 MB	1
rollup-base-public	418.07 MB	418.07 MB	1
rollup-block-root	1420 MB	1420 MB	1
rollup-merge	289 MB	289 MB	1
rollup-root	295.48 MB	295.48 MB	1

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

[vezenovm]

The tests in #7705 actually flagged a bug with how we were specifying instructions safe for hoisting. I have added a new method can_be_hoisted on Instruction which I go over in the Hoisting vs. Deduplicating section of the PR description as well as additional logic and tests to the loop invariant pass.

In summary, we do not want to hoist certain instructions (which may be safe for deduplication) when a loop may not execute.

[vezenovm]

The execution trace reports look to be bugged out. loop_invariant_regression with an inliner aggressiveness of 0 is giving me 379 opcodes as expected, but the report is saying that there is no difference.

EDIT: Ah it is the new reference_counts tests at different inliner settings

[github-actions]

Changes to number of Brillig opcodes executed

Generated at commit: 0b9db7264e237efca7a5fd51ad12dd307f6a8b4f, compared to commit: 58be0cd3897cd8ca3a99bac3b9fbbe561dfcb4a8

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
loop_invariant_regression_inliner_min	-690 ✅	-39.27%
loop_invariant_regression_inliner_max	-689 ✅	-64.51%
loop_invariant_regression_inliner_zero	-689 ✅	-64.51%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
brillig_cow_regression_inliner_min	220,181 (-180)	-0.08%
brillig_cow_regression_inliner_max	216,973 (-180)	-0.08%
brillig_cow_regression_inliner_zero	216,973 (-180)	-0.08%
poseidon_bn254_hash_inliner_zero	181,451 (-1,509)	-0.82%
poseidon_bn254_hash_width_3_inliner_zero	181,451 (-1,509)	-0.82%
poseidon_bn254_hash_inliner_max	150,934 (-1,509)	-0.99%
poseidon_bn254_hash_width_3_inliner_max	150,934 (-1,509)	-0.99%
poseidonsponge_x5_254_inliner_max	170,888 (-2,160)	-1.25%
regression_5252_inliner_max	851,025 (-10,800)	-1.25%
poseidon_bn254_hash_inliner_min	185,143 (-3,641)	-1.93%
poseidon_bn254_hash_width_3_inliner_min	185,143 (-3,641)	-1.93%
poseidonsponge_x5_254_inliner_min	205,645 (-5,110)	-2.42%
regression_5252_inliner_min	1,027,722 (-25,550)	-2.43%
poseidonsponge_x5_254_inliner_zero	201,569 (-5,110)	-2.47%
regression_5252_inliner_zero	1,004,827 (-25,550)	-2.48%
loop_invariant_regression_inliner_min	1,067 (-690)	-39.27%
loop_invariant_regression_inliner_max	379 (-689)	-64.51%
loop_invariant_regression_inliner_zero	379 (-689)	-64.51%