fix(brillig): Globals entry point reachability analysis

[vezenovm]

Description

Problem*

Resolves #7158

Was not sure whether to label this as a feat or a fix. It fixes repeated global initialization across multiple Brillig entry points, however, it is a pretty meaningful change in how we generate globals so I thought about labelling it a feat. As I labelled the issue a bug I have used the fix prefix.

Summary*

We now track globals Brillig artifacts by their entry point rather than having a single globals artifact for all entry points.

A few changes have been made:

1. We now track the used_globals by function rather than over the entire program.
2. We made a new BrilligGlobals context structure to simplify code gen for globals.
3. When generating BrilligGlobals we create some initial state from the function call graph.

    /// Both `used_globals` and `brillig_entry_points` need to be built
    /// from a function call graph.
    /// 
    /// Maps a Brillig function to the globals used in that function.
    /// This includes all globals used in functions called internally.
    used_globals: HashMap<FunctionId, HashSet<ValueId>>,
    /// Maps a Brillig entry point to all functions called in that entry point.
    /// This includes any nested calls as well, as we want to be able to associate
    /// any Brillig function with the appropriate global allocations.
    brillig_entry_points: HashMap<FunctionId, HashSet<FunctionId>>,

4. We then declare the globals for each entry point by looping over brillig_entry_points.
5. We construct a new mapping inner_call_to_entry_point

    /// Maps an inner call to its Brillig entry point
    /// This is simply used to simplify fetching global allocations when compiling
    /// individual Brillig functions.
    inner_call_to_entry_point: HashMap<FunctionId, Vec<FunctionId>>,

6. After compiling the globals we instantiate a map of entry points to global allocations.
7. The GlobalInit label has been updated to be associated with a function id representing an entry point. We now have GlobalInit(entry_point: FunctionId).

Additional Context

Most of the line additions are from the large global array included in test_programs/execution_success/global_var_regression_entry_points/src/consts.nr file. This change is most meaningful when tested with a large amount of globals across many entry points.

I compiled global_var_regression_entry_points with nargo compile --force --inliner-aggressiveness -100000000000000.
Running NOIR_LOG=trace nargo execute looking at nargo::ops::execute: close time.busy for multiple runs:
On master:
~35ms
This PR:
~7ms

About a 5x improvement in this example.

Looking at the execution report for rollup-block-root we look to see a large benefit:
This PR:

  {
    "artifact_name": "rollup-block-root",
    "time": "36.700s"
  },

While on master we are at ~41s. So about a 12% 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.

[TomAFrench]

Generally looks good, some nits.

[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: abdf7b9	Previous: 784a562	Ratio
sha256_regression	1.27 s	0.989 s	1.28

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

CC: @TomAFrench

[TomAFrench]

LGTM