Do not optimize IR without optimized outputs

[cameel]

Fixes #15062.

[cameel]

Note that these tests do not really test much. I added them so that this unintuitive option combination at least gets used, but the change is not really visible in compiler output. We won't detect anything unless it just crashes.

The difference is only visible in execution time. Both of these should now finish almost instantly:

time solc test/benchmarks/chains.sol --ir --optimize

time solc test/benchmarks/chains.sol --ir --optimize --via-ir

[nikola-matic]

Can I have another one with --ir-optimized --optimize --debug-info none, so that we can at least see the difference between outputs in this PR?

[cameel]

Added. Only for this case though because I don't think such a test is overly useful. --ir-optimized --optimize is the standard thing to do and the test is not checking its correctness anyway.

[github-actions]

This pull request is stale because it has been open for 14 days with no activity.
It will be closed in 7 days unless the stale label is removed.

[clonker]

At first I was tripping over the _optimized argument in generateIR which also set to true if viaIR and generateEvmBytecode were active even if the goal wasn't set to Optimized until it occurred to me that eg stack allocations would still be optimized even if no optimize cli option was given. I think it might have been clearer to me if the argument was called _runOptimizer instead, which is also closer to the naming in the optimizer settings struct. Still, I think it's fine as it is.

[cameel]

@clonker I think that the confusing thing is actually that the "optimized IR" output does not necessarily contain optimized IR :) It depends on the optimizer settings. It's just the main IR output that's used for compilation via IR and needing it for bytecode generation is natural, regardless of the optimization level. This is tripping people up all the time, especially on the CLI (@aarlt recently complained about that :)).

But I do think that things could be clearer. I wasn't fully satisfied with the initial version. I tried something new now - I replaced IRGenerationGoal with IROutputSelection, which should make it more apparent that it's really about outputs and not whether the optimizer runs or not. Let me know if you find that better.

[clonker]

You hit the nail on the head. That was the root of my confusion:) I like this version much better.

[cameel]

Rebased to resolve a conflict with #15228.

I also tweaked it a little more for readability:

• Renamed enableIRGeneration() to requestIROutputs() and adjusted its docstring. The new name should not suggest that it is the only way to enable IR generation.
• Introduced intermediate booleans and some comments for the condition in CompilerStack::compile(). Hopefully it makes it even easier to see at a glance what's happening there since the nitty-gritty details are encapsulated and when looking at a condition the name already tells you all you need to know.
• There were a few places with leftover goal naming (it's now called selection).