[flang-commits] [flang] [flang][Driver] Add support for -mllvm -print-pipeline-passes (PR #106141)

Tarun Prabhu via flang-commits flang-commits at lists.llvm.org
Tue Aug 27 16:28:47 PDT 2024


tarunprabhu wrote:

Output of `-fdebug-pass-manager`
```
Running analysis: InnerAnalysisManagerProxy<FunctionAnalysisManager, Module> on [module]
Running pass: EntryExitInstrumenterPass on _QQmain (4 instructions)
Running pass: EntryExitInstrumenterPass on main (4 instructions)
Running pass: AlwaysInlinerPass on [module]
Running analysis: ProfileSummaryAnalysis on [module]
Running pass: CoroConditionalWrapper on [module]
Running pass: AnnotationRemarksPass on _QQmain (4 instructions)
Running analysis: TargetLibraryAnalysis on _QQmain
Running pass: AnnotationRemarksPass on main (4 instructions)
Running analysis: TargetLibraryAnalysis on main
Running pass: PrintModulePass on [module]```

Output of `-mllvm -print-pipeline-passes`

```function(ee-instrument<>),always-inline,coro-cond(coro-early,cgscc(coro-split),coro-cleanup,globaldce),function(annotation-remarks),print```

The outputs above are for -O0 on a simple 3-line hello world program. It gets more interesting when optimizations are enabled and the input is non-trivial. 

> Is it very different and is the former the preferred format? 

In the second case, the output can be passed as is to the `-passes` option of `opt`. This is potentially useful to folks who want to experiment with a sequence of passes that is very similar to the compiler's defaults with potential additions/deletions. The former is "friendlier" and provides insights into analysis invalidations which is interesting in its own right. I don't think one is "more correct" or "better" than the other. I think having both is valuable.

> Is "stopping" the compilation the desired behaviour here?

My only concern with changing the behavior that is that we would have two frontends that are part of the same project with different behavior. It looks like they stopped compilation in `clang` to be consistent with the behavior of `opt`.

If tangling this with an "internal" LLVM command line option is objectionable (and I agree that it feels messy) we could make this a separate, first class option in `flang`. Would the `clang` folks be open to a similar change?

https://github.com/llvm/llvm-project/pull/106141


More information about the flang-commits mailing list