feat: Hoist constant allocation outside of loops

[sirasistant]

Description

Problem*

Avoids the runtime cost of reinitializing constants inside loops.

Summary*

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.

[github-actions]

Changes to Brillig bytecode sizes

Generated at commit: dc3cee93c0c9dc0a8133825dcefd8a371f525335, compared to commit: 68f3022fcdaab6e379e43091b3242e6ea51cff26

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
uhashmap	+40 ❌	+0.16%
hashmap	-1 ✅	-0.00%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
uhashmap	24,665 (+40)	+0.16%
hashmap	28,195 (-1)	-0.00%

[vezenovm]

Could we not do this during SSA and with more than just constants? We can have a loop invariant code motion pass that moves code that does the same thing to the pre-header of a loop.

[sirasistant]

That'd be compatible with the change in this pass, this is for the case where a value is a constant, we can hoist up the initialization of the constant. The pass that you're referring to would hoist instructions, however those have a harder requirement since all the dependencies of the instruction need to be available when hoisting it up. SSA currently doesn't have any instruction for initializing a constant, only brillig does so this is why it's done outside of SSA before brillig generation

[vezenovm]

SSA currently doesn't have any instruction for initializing a constant, only brillig does so this is why it's done outside of SSA before brillig generation

Ok fair

[sirasistant]

That will change for arrays with this one #6071

[vezenovm]

Not going to block on making find_blocks_in_loop shared in a separate module as this can be done in a separate PR. LGTM

[TomAFrench]

Agree on not blocking.