feat(brillig): SSA globals code gen

[vezenovm]

Description

Problem*

Resolves #6801

Summary*

Implements globals from SSA in Brillig gen. We create a new memory space GlobalSpace at compile time. Globals are declared in the global space and the linker is then used to connect these with our SSA functions. When converting SSA values we check whether we have a global and if so, look for the appropriate register that keys into the appropriate slot in the global space.

Additional Context

Some slight regressions are expected. Some reasons for this are laid out here #7021 (comment).

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.

[vezenovm]

The remaining regressions look to be due to dead globals not being removed. Will have a PR shortly.

[vezenovm]

The remaining regressions look to be due to dead globals not being removed. Will have a PR shortly.

I tried building off master originally but it was a lot easier to test, building off this branch. The work can be seen here in #7081.

diamond_deps_0_inliner_zero +2 ❌ +7.69%
modules_inliner_zero +2 ❌ +7.69%
modules_more_inliner_zero +2 ❌ +7.69%
no_predicates_basic_inliner_zero +2 ❌ +7.69%
traits_in_crates_1_inliner_zero +2 ❌ +7.69%
traits_in_crates_2_inliner_zero +2 ❌ +7.69%
fold_basic_inliner_zero +2 ❌ +7.69%

The globals DIE in #7081 is also not going to get rid of these extra instructions we see here. add_globals_init_instruction() makes an external call to our globals initialization. Without any globals to declare we will just execute a return instruction. Thus, we see an overhead of 2 instructions, a call and a return. We can get rid of this overhead, but it would require some larger changes that felt not worth holding up this PR on its own and could come in a follow-up. In general once this PR is in we will probably want to do a refactor that unifies how we track globals.

The affect on programs that make more meaningful usage of globals across functions can still be seen.
Some example bytecode size reductions:

global_var_regression_simple_inliner_min | 240 (-21) | -8.05%
bigint_inliner_min | 2,104 (-360) | -14.61%
bigint_inliner_zero | 1,906 (-332) | -14.83%

[vezenovm]

I look to be getting failures post AztecProtocol/aztec-packages#10605. Working on resolving it now.

EDIT: Ah it is all Global space too deep errors. I had to bump it to 16384.

[TomAFrench]

I look to be getting failures post AztecProtocol/aztec-packages#10605.

I assume that this is from the roots global. This isn't used in brillig code currently so I imagine this would be solved by the die pass PR

That said, as we know all of the globals at compile time we should be able to expand the space allocated as necessary. If so can you create a follow up issue?

[vezenovm]

That said, as we know all of the globals at compile time we should be able to expand the space allocated as necessary. If so can you create a follow up issue?

Yeah I'll make an issue for the max global space to be determined by the program rather than a hardcoded value.

[TomAFrench]

Do we need two lifetimes here? I'd expect that the globals would outlive 'block anyway so we can just reuse that lifetime.

[vezenovm]

Huh, not sure why I put them on the FunctionContext, good point. I think with how I have it now with the globals inside of FunctionContext I cannot avoid the second lifetime, but I will move it out of there and put it directly on BrilligBlock.