feat: Consider block parameters in variable liveness

[sirasistant]

Description

Problem*

Previously, on variable liveness we completely ignored block parameters, by allocating all the parameters of all blocks at the start of the function codegen and maintaining them allocated for the whole function.

Summary*

With this change, we add a definition point for block parameters and we start considering them and allocating and freeing them dynamically. This should save space in the stack, especially in heavily inlined functions with many blocks.

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.

[jfecher]

Is there a code example that prompted this? I'm interested to see how much this affects performance aside from memory usage if at all.

Edit: I see this originated from a slack convo. Can you add a test case for it?

[TomAFrench]

Agree that a test case would be good to have for this.

[sirasistant]

This optimization reduces stack usage, currently nargo compiles brillig functions with a maximum stack size. For functions that are very complex (like protocol-circuits test functions running in brillig for speed) this reduces the number of stack items greatly, for example, in the test public_kernel_app_logic::tests::clears_stack_if_current_call_revert_code_is_set in unconstrained mode the stack usage drops for more than half:

This also helps a bit with speed due to how we handle the stack in internal calls (dumping and restoring, due to not having instructions that operate relatively to the stack pointer yet) and I've seen an improvement of 2-4% in simulating big protocol circuits.
But this is mainly to run less against the stack limit.

[sirasistant]

Agree that a test case would be good to have for this.

I added a unit test for this but I'm not sure how can I do an e2e test for this given the current test infrastructure, unless I create a huge noir file with thousands of if statements, to simulate the case where a huge codebase runs against the stack limit because of block parameters

[sirasistant]

@jfecher @TomAFrench added a test that breaks in nightly and is fixed by this feature. I created a huge data structure and 5 if-else blocks to go over the 2048 stack items limit.

[sirasistant]

@TomAFrench Seems like I no longer have merge permissions

[TomAFrench]

Huh, that's odd. I'll take a look at it