feat(brillig): Centralize memory layout policy and reorganize memory regions

[vezenovm]

Description

Problem*

Resolves #9815

The issue highlighted in #9815 may not be a correctness bug per se, however, it does open up the possibility of breaking reproducible builds. The crux of the issue is that our byte code is dependent on the MAX_STACK_SIZE constant. This means that if the constant were to change that the same program would produce different byte code. If the constants were to ever change we would lose reproducible builds across those versions of the compiler. In general our memory layout is hard to reason about and needs to be made clearer.

Summary*

I ended up labeling this PR a feat as it does more than simply re-organize the memory regions.

Changes:

• Replaces hardcoded constants (MAX_STACK_SIZE, MAX_STACK_FRAME_SIZE, MAX_SCRATCH_SPACE) with LayoutConfig. Memory regions are now configurable per program compilation.
• Reorganizes memory regions in the following order:
  {reserved} {scratch} {globals} {entry_point (calldata + return data)} {stack} {heap}
• The most important effect of the new organization above is that instructions are no longer dependent on a constant max stack size.
• This change opens the door for downstream integrations (e.g., AVM) to more easily fine tune their memory layout.
• All register allocators (Stack, ScratchSpace, GlobalSpace) now compute start/end addresses from LayoutConfig rather than the hardcoded constants
• Entry point codegen now uses helper methods from the LayoutConfig as to centralize the memory layout policy
• The entry point code gen then returns the start of the stack memory region so that the CheckMaxStackDepth procedure has the accurate constant to check the stack pointer against
• I added a unit test that varies memory layouts to check for hidden dependencies. Without a LayoutConfig this test would not have been possible without config attributes or some other gross method. The tests also show how the Brillig artifacts are not affected at all by the memory layout and only the final entry point artifact is affected. In the previous memory layout every Brillig artifact was different when the constants were changed.

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.

[vezenovm]

Converting to draft due to fuzz test errors.

[vezenovm]

Converting to draft due to fuzz test errors.

I found the bug. This is ready for review again.

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Execution Time'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: 9409f87	Previous: 8d4f14d	Ratio
sha512-100-bytes	0.076 s	0.054 s	1.41

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

CC: @TomAFrench

[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: 9409f87	Previous: 8d4f14d	Ratio
test_report_zkpassport_noir-ecdsa_	3 s	1 s	3
test_report_zkpassport_noir_rsa_	2 s	1 s	2

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

CC: @TomAFrench

[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: c4a8dc1	Previous: 5e75f23	Ratio
rollup-checkpoint-root	243 s	190 s	1.28

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

CC: @TomAFrench

[TomAFrench]

Reorganizes memory regions in the following order:
{reserved} {scratch} {globals} {entry_point (calldata + return data)} {stack} {heap}

I'm going to be reviewing this PR today but this is one potential source for concern. The public_dispatch function in aztec contracts receives more calldata than its function signature implies so if we're making an assumption that we know the size of the calldata here then that could cause problems.

We don't have any tests for this either currently so there's nothing to enforce we don't break this in future.

Shouldn't be an issue.

[TomAFrench]

Looks good, some small nits

[vezenovm]

Shouldn't be an issue.

Just for additional clarity we currently set the heap to start after the entry point memory region

noir/compiler/noirc_evaluator/src/brillig/brillig_ir/entry_point.rs

Line 80 in 2fd19e8

(self.calldata_start_offset() + calldata_size + return_data_size).into(),