The core idea is to fully parse the text without trying to identify
passes or structure. This is done with a single state machine. There
were various bugs in the logic around this previously that were repeated
and scattered across the code. Having a single routine makes it much
easier to fix and get correct. For example, this routine doesn't suffer
from PR28577.
Then the actual pass construction is handled using *much* easier to read
code and simple loops, with particular pass manager construction sunk to
live with other pass construction. This is especially nice as the pass
managers *are* in fact passes.
Finally, the "implicit" pass manager synthesis is done much more simply
by forming "pre-parsed" structures rather than having to duplicate tons
of logic.
One of the bugs fixed by this was evident in the tests where we accepted
a pipeline that wasn't really well formed. Another bug is PR28577 for
which I have added a test case.
The code is less efficient than the previous code but I'm really hoping
that's not a priority. ;]
Depends on D22723
Do you need error-checking here to verify that InnerPipeline is empty? Just from staring at the code it seems like gvn(foo,bar) will just be silently accepted with the (foo,bar) ignored.
I think down the road it actually would be useful to allow passes to take "arguments". E.g. inline(150) or instcombine(expensivecombines=true). That way we can run two inliners in the same pipeline but with different thresholds.
The instcombine case is actually interesting because currently there is no way to specify an instcombine pass that does not do the "expensive" combines. This means that this textual pipeline description cannot actually describe the O2 pipeline correctly (this is an issue with the old PM too, of course, so it isn't a high priority to fix).