Improved optimization configuration and defaults

[vezenovm]

Problem

We now have many different SSA passes and even a couple security checks now (e.g. #6658).

The individual SSA passes can be run in different configurations themselves (e.g. inliner aggressiveness) as users may want something different out of their compilation result (optimized for execution vs. optimized for bytecode size).

We currently allow developers to configure whether to run a pass or run a pass with a certain setting through compilation flags in nargo. We have added the flags as our needs have required them, but as we add more optimizations, we will want a nicer way of configuring optimizations and default settings.

Happy Case

We could determine different groupings of optimizations, such as loop optimizations, inliner optimizations, constant vs. constraint folding. We can then have flags for various optimization groups such as -O0 = all on and -O3 = all off.

Users should be able to set defaults for SSA optimizations in the manifest similarly to expression_width. If I know I want to optimize for bytecode size I should be able to set inliner_aggressivenes = -1000000000 in the Nargo.toml without having to pass a flag every time.

There are a couple ways we can go for grouping optimizations which we can discuss. Posthing this issue is posted as an initial tracking issue.

Workaround

Yes

Workaround Description

Manually turning passes on/off and rebuilding Noir

Additional Context

No response

Project Impact

Nice-to-have

Blocker Context

No response

Would you like to submit a PR for this Issue?

None

Support Needs

No response

[TomAFrench]

I think part of this issue is that we probably want to split the command line options struct from what's actually passed into the compiler. It's getting complex enough that we don't want to be forced into using the same layout for both.

Edit: yeah... I'm basically just restating the OP back to you. So agreed, I guess.

[michaeljklein]

While we're refactoring optimization configs, I'd like to consider adding per-module or per-function scopes to optimization configs, e.g. specifying a large inliner_aggressiveness for only one function.