optLevel should be fully expressible as a set of individual optimization flags

https://mail.haskell.org/pipermail/ghc-devs/2021-October/020253.html

In particular:

But the point is, I do not want to set optLevel. I want to turn on individual optimizations. But as it stands today, if I turn on any optimizations, that doesn’t do anything unless I also set optLevel to >= 1.

Yes I agree. Nothing should consult optLevel; indeed maybe we shouldn’t even record it permanently.

The place in Pipeline that Sylvain identified is most important.

So when we compute the CoreTodos, instead of looking at the optLevel, we’d consult the set of optimizations turned on, and go “yup, at least one of these needs core-to-core simpl passes, so we better get on it”, going to the same branch that current is gated by optLevel >= 1.

Yes I agree with this. Another alternative might be to kill off the -O0 pipeline entirely (in GHC.Core.Opt.Pipeline.getCoreToDo) and just have one pipeline that does not-very-much when no optimisations are enabled. This would be more robust (no need to have a list of flags to consult to decide which path to follow), but could have unforeseen consequences (what happens in the -O pipeline if all optimisations are off? Same as the -O0 pipeline?).