Hi,
I’ve recently started adding code-gen support in Flang’s new compiler driver. As Flang leverages some of MLIR’s standard passes for code-generation, this involves a bit of integration. One item that we are currently discussing are command line options [1].
More specifically, MLIR provides PassPipelineCLParser to register various standard pass options. IIUC, PassPipelineCLParser uses CommandLine, but in Flang we use clangDriver to manage command-line options for us. That library builds on top of OptTable. We probably should avoid mixing different APIs for command-line options (llvm::cl and OptTable), so PassPipelineCLParse is not really an option in Flang.
What would be the recommended approach to make MLIR pass options available in the Flang driver? Are there any other tools that don’t use llvm::cl but still get access to MLIR pass options? I’m completely new to MLIR, so might be missing something obvious here.
EDIT: After posting this I realised that this is somewhat similar to Clang and LLVM passes. I’m guessing that we should basically be adding -mmlir.
Thank you,
-Andrzej
[1] https://github.com/flang-compiler/f18-llvm-project/pull/1008
Hey,
In one case.(not that I’m recommending it at all, just saying 
) we pass them via environment variable and invoke parsing explicitly. One could also follow the precedent of Xclang mllvm approach (as your edit also points too).
I’d be cautious about exposing the flags directly except for testing/development: the pass command line options are intended for a different user than flang is, with different stability expectations. You’d probably not want users to set some of the things that mlir-opt can do, nor would you want them to rely on it. So exposing something higher level/more stable and then constructing the passes as desired would probably work out better - additional cost that looks like duplication in some cases, but should be more sustainable.
– Jacques
I’d be very cautious about exposing this being a flag that make it very clear that these aren’t stable and meant for development / debugging purpose only: they can change from one Flang release to another.
If there are options that you’d like to expose to the user in a stable way, they should be wrapped with OptTable options (for example -funroll-loops clang option is defined here: llvm-project/clang/include/clang/Driver/Options.td at main · llvm/llvm-project · GitHub and clang will map it to the correct set of LLVM construct, hopefully not using a cl::opt but using a C++ API to LLVM).
Thank you for claryfying!
Noted. If we do expose it, it will only be available in the frontend driver, which is a developer tool with no guarantees about the interface (similar to clang -cc1). We will make it clear that this is “at-your-own-risk” type of thing.