[PATCH] D108298: [WIP][NPM] Print '-passes' compatible string for built pipeline.

[Bjorn Pettersson via Phabricator via llvm-commits]

bjope added a comment.

In the end, when reducing a failure, we want to get down to a single pass pipeline, `-passes='pass-name<params>'`. Today, when `-debug-pass-manager` , `-print-changed`, etc. only prints the class name one need to open up the source code and try to map the class name to a pass name, and then also finding out which parameters that was used when it crashed.
Being able to print out the pipeline textually, after having applied all extensions etc, just before starting to run the pipeline (as this patch is aiming at) shouldn't be much different. And isn't printing the pipeline textually exactly what a tool such as opt-bisect wants to do when having finished up bisecting (regardless if the final reduced pipeline contains one or more passes).

I really think it would be useful to get the `pass-name<params>` printed automatically. Hence, there needs to be some kind of mapping from class name to pass name to exist somewhere, but we should also add support to print the parameters.
(Well, another solution to avoid the class name to pass name map would be to use class name all over the place, but that is quite a large change, specially while still having support for legacy PM.)

There are probably lots of different ways how to implement these things. Current situation with having information about a Pass in the PassRegistry.def and how to parse parameters in PassBuilder.cpp is a bit clumsy. All the information should probably be self-contained in the pass implementation somehow (I think this has been discussed earlier).
Not sure however if a potentially bad original design should stop us from adding the functionality that is missing. Hopefully someone will be eager to refactor things if the basic design of the new PM implementation is wrong, but I think it is even worse that the new PM implementation is lacking functionality.  Not saying that I'm against refactoring first and adding new functionality afterwards, but sometimes it is hard for someone new to understand how to refactor things, while it might be easy to build upon the existing design.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108298/new/

https://reviews.llvm.org/D108298