feat(ssa): Treat globals as constant in a function's DFG

[vezenovm]

Description

Problem*

Resolves TODO leftover from #6985

Also mentioned in this comment #7021 (comment).

Summary*

In order to re-use our existing instruction simplification we need to be able to access globals inside of the DFG. In order to do this I have created a new GlobalsGraph type that now exists as an Arc<GlobalsGraph> in the DataFlowGraph. Arc is used so that we can share the GlobalsGraph across all functions. However, we will have to eat a cloning cost as we now place the globals information in all functions rather than simply placing it in the main Ssa object.

Additional Context

In #6985 we only added a Value::Global, but globals support both numeric constants and array constants. This means that we can have overlapping instruction ids in the function graph and the globals graph. To avoid having to add placeholder instructions like we do for values, when checking for a constant array instruction we also check whether the value tied to that instruction is specified as a global. If the instruction is specified as global we look for the instruction in the globals graph.

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]

Compilation Memory Report

Program	Peak Memory	%
keccak256	77.63M	0%
workspace	123.86M	0%
regression_4709	424.14M	0%
ram_blowup_regression	1.58G	0%
rollup-root	373.61M	82%
rollup-merge	229.80M	12%
rollup-block-root-single-tx	15.97G	100%
rollup-block-root-empty	223.97M	9%
rollup-block-root	15.97G	100%
rollup-block-merge	373.60M	82%
rollup-base-public	2.51G	100%
rollup-base-private	901.24M	341%
private-kernel-tail	207.30M	23%
private-kernel-reset	669.37M	298%
private-kernel-inner	294.51M	75%

[asterite]

Looks good!

[github-actions]

Changes to number of Brillig opcodes executed

Generated at commit: 415d0e5fe50a47db598f65f4a63878f7c99887d0, compared to commit: 8d2a2ddcd90053483cc62c2cdf0797bee3490b10

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
6_inliner_zero	-110 ✅	-1.40%
regression_4449_inliner_zero	-3,849 ✅	-1.67%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
ram_blowup_regression_inliner_zero	814,524 (+3,179)	+0.39%
sha256_var_padding_regression_inliner_zero	265,695 (+788)	+0.30%
sha256_regression_inliner_zero	155,443 (+388)	+0.25%
sha2_byte_inliner_zero	72,372 (-55)	-0.08%
array_dynamic_blackbox_input_inliner_zero	21,268 (-19)	-0.09%
ecdsa_secp256k1_inliner_zero	7,610 (-54)	-0.70%
conditional_1_inliner_zero	5,514 (-55)	-0.99%
array_dynamic_nested_blackbox_input_inliner_zero	4,491 (-59)	-1.30%
conditional_regression_short_circuit_inliner_zero	7,820 (-110)	-1.39%
6_inliner_zero	7,740 (-110)	-1.40%
regression_4449_inliner_zero	227,252 (-3,849)	-1.67%

[vezenovm]

Program Brillig opcodes (+/-) %
6_inliner_zero -110 ✅ -1.40%
regression_4449_inliner_zero -3,849 ✅ -1.67%

Nice, looks like we already see some benefits with different inliner aggressiveness settings. There looks to be some slight regressions as well. This is most likely due to us still repeating certain initialization of globals and will require #7021.