[flang-dev] Flang driver - next steps
Mehdi AMINI via flang-dev
flang-dev at lists.llvm.org
Wed Sep 29 11:24:51 PDT 2021
Something annoying with the clang driver is the lack of
reproducibility of the optimization pipeline (`clang -O3` and `opt
-O3` gives different results).
It'd be great if flang was set up from the beginning to avoid this
kind of issues!
Otherwise your plan looks good to me :)
On Wed, Sep 29, 2021 at 8:05 AM Andrzej Warzynski via flang-dev
<flang-dev at lists.llvm.org> wrote:
> [Flang == "LLVM Flang"]
> Until recently we were focusing on replacing `f18` (the old driver) with
> `flang-new`, the new driver. This was completed in . 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 . Note that we are only able to work on the
> above in the `fir-dev` branch of f18-llvm-project .
> # *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`  bash script as e.g.
> `flang-to-gfortran` (or something similar)?
> Thank you for reading,
>  https://reviews.llvm.org/D105811
>  https://github.com/flang-compiler/f18-llvm-project/pull/1008
>  https://github.com/flang-compiler/f18-llvm-project
>  https://github.com/llvm/llvm-project/blob/main/flang/tools/f18/flang
> flang-dev mailing list
> flang-dev at lists.llvm.org
More information about the flang-dev