[flang-dev] RFC: Is `flang-new` ready to replace `f18`?
Andrzej Warzynski via flang-dev
flang-dev at lists.llvm.org
Tue May 11 07:32:47 PDT 2021
Hello all,
Here's a quick update on what's happened since my last e-mail.
In the previous Flang community technical call we discussed enabling the
new Flang driver by default. This change has now been merged upstream:
https://reviews.llvm.org/D101842. Please remember to set
`FLANG_BUILD_NEW_DRIVER` to `Off` if you don't want to build the new
driver (and to avoid the dependency on Clang).
Our next step is to find a way to use flang-new, the new driver, to
`unparse` source files before calling an external Fortran compiler for
code-generation. That's one feature that's available in `f18` and which
we won't replicate in `flang-new`. Instead, we'll try to implement this
in a wrapper script. Once this is ready, we'll suggest that `f18` is
removed.
Please let me know if you have any questions!
Thank you,
-Andrzej
On 03/05/2021 14:19, Andrzej Warzynski via flang-dev wrote:
> Hi,
>
> This is just a quick summary of the discussion that we had on this RFC
> on Slack and during our most recent community call.
>
> * Peter Klausler and Steve Scalpone do use `flang` (the bash wrapper
> script for `f18`) to call external compilers. They suggest that we find
> a way to replicate this with `flang-new` (the new driver) before `f18`
> can be removed.
> * Peter Klausler asked about the dependency on Clang and the ability to
> build out-of-tree. Just to clarify: the new driver can be built
> out-of-tree and we have a buildbot to make sure that this works fine:
> https://lab.llvm.org/buildbot/#/builders/149. The dependency on Clang
> will take a while to be removed. There's been no active development in
> this direction since [1]
> * Johannes Doerfert suggested that the dependency on Clang shouldn't be
> a blocker. Flang will depend on Clang regardless of the new driver
> (through the OpenMP runtime). Also, given previous design decisions, it
> feels that compiler build times are not the highest priority for Flang.
>
> Please correct me if I misunderstood anything or missed any comments.
>
> Thank you for your feedback!
> -Andrzej
>
> [1] https://lists.llvm.org/pipermail/cfe-dev/2020-November/067263.html
>
> On 27/04/2021 10:50, Andrzej Warzynski via flang-dev wrote:
>> Hello,
>>
>> As the new Flang driver has recently reached feature parity with the
>> "throwaway" driver, I wanted to ask whether we are ready to remove `f18`?
>>
>> To better inform this discussion, below you will find an up-to-date
>> status update. I wanted to avoid sending separate e-mails - I hope
>> that this fine!
>>
>> *SUPPORTED OPTIONS*
>> A summary of the supported options is available in [1]. I shared that
>> spreadsheet in November last year [2]. I've been updating it while new
>> features were being added. Most notable changes:
>> * `-fdebug-no-semantics` is replaced with 2 options:
>> `-fdebug-unparse-no-sema` [3] and `-fdebug-dump-parse-tree-no-sema` [4]
>> * `-fconvert=swap/-byteswapio` is not supported in the "throwaway"
>> driver [5] and hence has not been added in `flang-new`
>> * `-ffree-line-length=<arg>` is currently not supported by the
>> frontend and hence has not been added in `flang-new`
>> * `-futf-8`/`-flatin` are replaced with `-finput-charset=<val>` (the
>> latter is the GCC/Clang spelling that we didn't know about when
>> compiling [1])
>> As discussed previously [2], `flang-new` uses GCC style spellings.
>>
>> *TESTING*
>> Apart from adding tests specifically for the new driver, all existing
>> Flang tests have been ported to use `flang-new` when
>> `FLANG_BUILD_NEW_DRIVER` is set. In order to facilitate this, 2 new
>> LIT variables have been added. Their meaning depend on whether
>> `FLANG_BUILD_NEW_DRIVER` was set or not (unset by default):
>> * `%flang` expands to either `flang-new` or `f18` and represents
>> compiler driver
>> * `%flang_fc1` expands to either `flang-new -fc1` or `f18` and
>> represents frontend driver
>> This is similar to `%clang` and `%clang_cc1` in Clang and allows a
>> clear separation between the drivers when testing. Please use
>> `%flang_fc1` or `%flang` in your tests from now on. `%f18` will be
>> removed shortly [6]. In terms of upstream testing, all but 1 of our
>> Buildbot workers already set `FLANG_BUILD_NEW_DRIVER` to `On` (i.e.
>> test with the new rather than the old driver).
>>
>> *NEW VS OLD DRIVER - COMPARISON*
>> In terms of _driving the frontend_, `flang-new -fc1` and `f18` are
>> fully compatible. Otherwise we wouldn't be able to run the frontend
>> tests with the new driver.
>>
>> Comparing `flang-new` and `f18` in terms of _driving the whole
>> compiler_ (frontend/codegen/asm/linking) is tricky. The former does
>> not support code-generation yet (it's not available in
>> llvm-project/flang yet). The latter calls a separate Fortran compiler
>> to do the code-generation, so that's more like an experimental
>> feature. This won't be supported in `flang-new`, as discussed in [2].
>>
>> Lastly, the new driver introduces a dependency on Clang. The steps to
>> remove this dependency were outlined in [7], but we've not been able
>> to make any progress here.
>>
>> *ADDING NEW OPTIONS*
>> All options for the new Flang driver are defined in Options.td in
>> Clang [8]. I will be documenting the steps required to add new options
>> in the coming weeks. In the meantime, please feel free to ask me
>> directly (Slack/e-mail) if you have any questions. You can also use
>> one of the existing options for reference.
>>
>> *NEXT STEPS*
>> Maintaining multiple drivers is not ideal and we would like to replace
>> `f18` with `flang-new` sooner rather than later. We are keen do it
>> now, despite the differences between `flang-new` and `f18` highlighted
>> above. The new driver covers all use cases that are relevant for us,
>> but we appreciate that this might not be the case for other community
>> members.
>>
>> Taking the above into account, do you think that `flang-new` is ready
>> to replace `f18`? If not, what's the blocking issue for you? Is it:
>> * the ability to call an external compiler?
>> * the dependency on Clang?
>> * something else?
>> Please let me know if there's anything that's unclear!
>>
>> Thank you for reading and for your feedback!
>>
>> -Andrzej
>>
>>
>> [1]
>> https://docs.google.com/spreadsheets/d/1JRe39lP_KhtkYxFEIvwrCFlE5v1Ofa_krOHI-XXXWPY/
>>
>> [2] https://lists.llvm.org/pipermail/flang-dev/2020-November/000588.html
>> [3]
>> https://github.com/llvm/llvm-project/blob/main/flang/test/Parser/omp-allocate-unparse.f90
>>
>> [4]
>> https://github.com/llvm/llvm-project/blob/main/flang/test/Driver/dump-parse-tree-no-sema.f90
>>
>> [5]
>> https://github.com/llvm/llvm-project/blob/b6db6f5530d2df8bc3a1acf6d68b2bfa2bd053b4/flang/tools/f18/f18.cpp#L671
>>
>> [6] https://reviews.llvm.org/D101281
>> [7] https://lists.llvm.org/pipermail/cfe-dev/2020-July/066393.html
>> [8]
>> https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Driver/Options.td
>>
>> _______________________________________________
>> flang-dev mailing list
>> flang-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev
> _______________________________________________
> flang-dev mailing list
> flang-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev
More information about the flang-dev
mailing list