fix(ssa): Swap Brillig index shift and DIE in minimal pipeline

[aakoshh]

Description

Problem*

Resolves #8941

Summary*

Changes the order of "Dead Instruction Elimination" and "Brillig Array Get and Set Optimizations" in the --minimal-ssa pipeline to do the DIE as the last step.

The reason is the Brillig array index optimisations shift constant indexes by an offset, and then insert the new constants into the DFG; when that happens the DFG tries to reuse existing constants and return their IDs, and these constants can come from the global as well as local values. If it comes from a global, it can mark a global value as used even when it wasn't otherwise referenced.

The DIE pass gathers used global values, but in the minimal pipeline it came before the index offsets, so it worked with stale data.

Additional Context

I don't know if this is an intended reuse, I suppose it might save some allocations the Brillig VM if we reuse global values, although it seems dubious if this is the only use of a global value. Nevertheless, swapping the order doesn't seem to have any detrimental effect.

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]

⚠️ 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: 37b8ca0	Previous: 51f6b7c	Ratio
rollup-merge	0.004 s	0.003 s	1.33

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

CC: @TomAFrench

[vezenovm]

although it seems dubious if this is the only use of a global value

It is not. Global values are declared by users. We just also use them within the compiler for sharing constants across functions. We may want to move to only sharing array constants in globals and always inlining simple numeric constants, but that would be a separate experiment.

[aakoshh]

It is not. Global values are declared by users.

I didn't mean it was wrong to use it, or that it's artificially introduced into the globals, just wanted to say that it seems a bit random if e.g. a single array item ends up surviving from the globals only because a shift ends up matching its value. In other words, it's not like we piggy back on a global that has its use on its own in the current SSA, but this way we save an extra slot, but rather this is the only thing that keeps it being used. There is no mechanism to seek opportunities for sharing, by elevating constants into the global space.

Anyway, thanks for confirming that it works as intended!

[vezenovm]

In other words, it's not like we piggy back on a global that has its use on its own in the current SSA, but this way we save an extra slot, but rather this is the only thing that keeps it being used. There is no mechanism to seek opportunities for sharing, by elevating constants into the global space.

Ah I see. We do in fact have a mechanism for elevating local constants to global constants, it just occurs after SSA gen and as part of Brillig gen. You can look in brillig_globals.rs for more information and here is an example unit test

noir/compiler/noirc_evaluator/src/brillig/brillig_gen/brillig_globals.rs

Line 500 in d1e55d9

fn hoist_shared_constants() {