chore(ssa): Activate loop invariant code motion on ACIR functions

[vezenovm]

Description

Problem*

Part of general effort to optimize the compiler.

Summary*

Loop invariant code motion most affects the Brillig runtime, as in that runtime we actually keep loops and may possibly re-execute unnecessary instructions. In ACIR all loops are unrolled so when the pass was introduced I was thinking that running it may be an unnecessary cost when compiling to ACIR. However, the pass should provide benefits to the compilation pipeline itself.

For ACIR programs with large upper loop bounds, unrolling is oftentimes the pass that takes up the most time. If we can reduce the number of opcodes inside of a loop, unrolling should take less time. This becomes most obvious when paired with #6782, as a large constant array is most likely going to be one of the heavier instructions to process due to its large number of values.

We probably will want some kind of heuristic to determine whether it is worth it to run this pass for ACIR. Running this pass in ACIR is still most likely unnecessary for the majority of programs, but will benefit those programs with lots of heavy loop invariants.

Additional Context

Compiling the blob circuit:
Master:
Loop invariant code motion - 0ms
Unrolling - 44s
This branch w/ #6784:
Loop invariant code motion - 152ms
Unrolling - 27s (38.6% improvement)

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]

Peak Memory Sample

Program	Peak Memory	%
keccak256	79.14M	1%
workspace	121.86M	-1%
regression_4709	295.98M	0%
ram_blowup_regression	2.44G	0%
private-kernel-tail	210.43M	0%
private-kernel-reset	862.21M	0%
private-kernel-inner	307.94M	0%
parity-root	175.78M	0%

[github-actions]

Compilation Sample

Program	Compilation Time	%
sha256_regression	0m1.493s	-14%
regression_4709	0m0.789s	-50%
ram_blowup_regression	0m17.218s	-2%
private-kernel-tail	0m1.248s	0%
private-kernel-reset	0m8.621s	-14%
private-kernel-inner	0m2.809s	2%
parity-root	0m0.939s	7%
noir-contracts	2m46.796s	4%

[jfecher]

I see a good enough improvement in regression_4709 alone that I'd say this is worth merging as-is

[vezenovm]

I see a good enough improvement in regression_4709 alone that I'd say this is worth merging as-is

Yeah looks like it may be good to do on its own even without #6784. I have marked the PR ready for review.

[jfecher]

LGTM