[Compiler]Define a generic set of pipelines

[linuxlonelyeagle]

Is your feature request related to a problem? Please describe.
The reason I don't think the current pipeline is elegant is because all the pipelines are separated. For example, for a model, we use mlir upstream and buddy passes in order to lower that model, and many times different pipelines are used for different models, and I don't think this is elegant enough. I envision that we can design our own pipeline, in which case we only need to use this one pipeline when lowering code and models.

Describe the solution you'd like
I don't have too many good ideas at the moment, I don't know what you think @zhanghb97 .

[zhanghb97]

GraphDriver will manage the lowering pipeline; the infra is coming. We are also exploring an automatic tool for pipeline generation.

[chenghuaWang]

I noticed that you are doing vectorization manually. midend/conversion. Why not add a pass pipeline that can do tiling and vectorization for all linalg ops?

[zhanghb97]

We use two strategies to perform vectorization.

• Manually vectorization algorithm for named linalg ops.
• Generic vectorization for generic linalg ops.

[linuxlonelyeagle]

In my opinion, while the method of auto-generating the pipeline via GraphDriver and the write tool is good, it's not the best way to do it, and while it's possible to do it any way, there's always a good and a bad way to do it.

• I think the pipeline should be managed elegantly, not just so that the code can be brought down to a certain level.That's why I brought up this issue.We need to get more granular with pipeline.
• I think we can implement coarse-grained passes to manage fine-grained passes. Then we organize the coarse-grained passes into a pipeline and everything runs on that pipeline.
• This is easy to debug. Because we wrap fine-grained passes with coarse-grained passes. if you use a tool to generate a pipeline, and the pipeline is long, it will be hard to debug.
• When the IR runs a certain pass, we can visualize the state of the IR more intuitively.

There may not be many advantages I can think of, but I do think this is the best way to go. My purpose in bringing up this issue was never how to lower IR. but how to fine tune the management of the pipeline.

[zhanghb97]

This is indeed an ideal design, but the situation is more complicated. Do you have any specific proposals? Several issues need to be considered:

• how to manage different inputs? (With mixed-level ops, custom dialects, etc.)
• how do coarse-grained passes determine the fine-grained passes?
• how to use "everything runs on that pipeline" to generate heterogeneous code?

[linuxlonelyeagle]

• how to manage different inputs?
  We can integrate all the dialect in buddy-opt.
• how do coarse-grained passes determine the fine-grained passes?
  I think that's the heart of the issue, and maybe we need to have a clearer perception of a lot of the passes.There's not much to think about at the moment.
• how to use "everything runs on that pipeline" to generate heterogeneous code?
  Regarding the heterogeneous code, I think we can run the pass that generates the heterogeneous code after running it to a certain pass. e.g. Gemmini or rvv.

Well, all in all, this is just a preliminary idea at the moment, and I don't have a good solution for it, but I think we can keep this issue, and if there are any good ideas, you can leave a comment below, and I think there will be a day when we can solve this problem.