[flang-dev] Flang driver - next steps

[Andrzej Warzynski via flang-dev]

Hello,

[Flang == "LLVM Flang"]

Until recently we were focusing on replacing `f18` (the old driver) with 
`flang-new`, the new driver. This was completed in [1]. The natural next 
step is to add support for code-generation and linking phases. Although 
we have been discussing most of this in our community calls, not 
everyone has been able to attend them. Here's a quick overview and some 
open questions.

# *Code generation*
This will almost entirely be implemented inside the frontend driver 
(i.e. llvm-project/flang). It will support the following stages:
   1. ParseTree --> MLIR
   2. MLIR --> LLVM IR
   3. LLVM IR --> assembly/object code
This might be better expressed in terms of compiler options. Basically, 
we plan to add the following options to the frontend driver:
   * -emit-mlir (ParseTree --> MLIR)
   * -emit-llvm (ParseTree --> MLIR --> LLVM IR)
   * -emit-obj (ParseTree --> MLIR LLVM IR --> object code)
   * -S (ParseTree --> MLIR --> LLVM IR --> assembly)
   * -save-temps/-save-temps=<value>
   * --target=<value>
   * -print-target-triple
   * -print-targets
Do you see any key code-generation related options missing here? We 
would like to keep this list short and focus on the bare minimum that 
will best inform the design. Note that adding these options will lead to 
some duplication in implementation _and_ functionality between 
`flang-new -fc1` and `bbc`/`tco`. We will need to make sure that these 
tools stay in sync and that the level of testing for all is similar.

This work has already started and a patch implementing `-emit-mlir` is 
currently under review [2]. Note that we are only able to work on the 
above in the `fir-dev` branch of f18-llvm-project [3].

# *Linking*
This phase will be managed by `clangDriver`, so it will likely require 
some changes there. Compared to Clang, we do have one additional 
intermediate representation to support (MLIR). We may want to/need to 
make `clangDriver` aware of it. Otherwise, do you see anything that we 
might be missing here? Or any specific options that may require extra 
work within LLVM Flang?

We have not started working on this yet. Instead, we have been just 
using `clang` manually to drive the linking.

# *Implementation details*
Quite a few of us have been using glue scripts to achieve end-to-end 
workflow (i.e. Fortran source --> executable). We want to focus on 
supporting this workflow in `flang-new` as soon as we can. We will try 
to achieve this without major design changes and that's why we want to 
focus on the bare minimum of options required here.

However, we probably want to introduce `ParseTreeConsumer` and 
`FIRConsumer` (or something similar) at some point. These abstraction 
layers would be similar to `ASTConsumer` in Clang and would allow a 
cleaner separation between the driver and various consumers of the 
intermediate representations in LLVM Flang. This could be a good time to 
introduce them, but it's an "implementation detail" that we can 
refine/revisit later.

# *Bash script*
Once `flang-new` is capable of generating executables, shall we rename 
it as `flang` and then rename the `flang` [4] bash script as e.g. 
`flang-to-gfortran` (or something similar)?

Thank you for reading,
Andrzej


[1] https://reviews.llvm.org/D105811
[2] https://github.com/flang-compiler/f18-llvm-project/pull/1008
[3] https://github.com/flang-compiler/f18-llvm-project
[4] https://github.com/llvm/llvm-project/blob/main/flang/tools/f18/flang