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 setoptLevel
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
CoreTodo
s, 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 byoptLevel
>= 1.Yes I agree with this. Another alternative might be to kill off the
-O0
pipeline entirely (inGHC.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?).