To support options like -print-before=<pass> and -print-after=<pass>
the PassBuilder will register PassInstrumentation callbacks as well
as a mapping between internal pass class names and the pass names
used in those options (and other cmd line interfaces). But for
some reason all the passes that takes options where missing in those
maps, so for example "-print-after=loop-vectorize" didn't work.
This patch will add the missing entries by also taking care of
function and loop passes with params when setting up the class to
pass name maps.
One might notice that even with this patch it might be tricky to
know what pass name to use in options such as -print-after. This
because there only is a single mapping from class name to pass name,
while the PassRegistry currently is a bit messy as it sometimes
reuses the same class for different pass names (without using the
"pass with params" scheme, or the pass-name<variant> syntax).
It gets extra messy in some situations. For example the
MemorySanitizerPass can run like this (with debug and print-after)
opt -passes='kmsan' -print-after=msan-module -debug-only=msan
The 'kmsan' alias for 'msan<kernel>' is just confusing as one might
think that 'kmsan' is a separate pass (but the DEBUG_TYPE is still
just 'msan'). And since the module pass version of the pass adds
a mapping from 'MemorySanitizerPass' to 'msan-module' one need to
use 'msan-module' in the print-before and print-after options.
By adding some printouts when this check fails, I get this (after also having applied D105007):
Not sure if we need to add a one-to-many map to handle some of the above. Or if for example early-cse-memssa should be called early-cse<memssa> to indicate that it is a specialized version of early-cse.
For passes like ee-instrument. and post-inline-ee-instrument it might be trickier. Should enabling print-after for one of those trigger IR printouts for both? I.e. should they be seen as two different passes, or parameterized versions of the same pass?
I also think it is just confusing to have both simplifycfg and simplify-cfg<>, as well as both simple-loop-unswitch and unswitch<>.
Not sure what to do with the sanitizer passes that both exist as module and function passes, using the same class name.