[flang-dev] [RFC] Frontend driver: action vs non-action options

Wed Oct 13 11:32:54 PDT 2021

One way to see it is that an action controls what the output of the
invocation is, i.e. what is written to the file specified by -o (or
stdout). Specifying multiple actions would be a contradiction in what
would be written to the output file.

IMHO the compiler should error-out if multiple (different) actions are
specified. If one wants to have multiple outputs (such as the AST dump
as well as the assembly output) one needs to invoke the compiler
multiple times. An alternative would be to have options that specify
additional output file, as -MF does (i.e. -M/-MF is not an action but
an option).

In some contexts it may make sense to allow contradicting options on
the command line as a result of a build system combining multiple
sources for flags. For instance, CMAKE_BUILD_TYPE=Release will add -O3
by default, but I can override this with e.g. CMAKE_CXX_FLAGS=-O2. I
don't think this makes sense with actions as the output what the build
system expects would be completely different.

Thanks to Andrej's list, there are quite some dump options. Maybe it
makes sense to have a single dump action (llvm.org/PR52095) and an
additional option for selecting what is to be dumped to avoid multiple
invocations. Eg. `-fdump=unparse,symbols -o dump.txt`. Alternatively,
like `-M`, have options that specify where the dump output goes. These
could be added e.g. CMAKE_CXX_FLAGS to have dumps written next to the
main output while using the main build system.

As Andrej mentioned, the clang/flang option parsing system behaviour
to ignore all but the last for exclusive options. Maybe we should
extend it such that in the .td file we can specify that it is an
error/warning if mutually exclusive options are specified?

Michael

Am Mi., 13. Okt. 2021 um 09:39 Uhr schrieb Andrzej Warzynski via
flang-dev <flang-dev at lists.llvm.org>:
>
> Hi All,
>
> [Flang = LLVM Flang]
>
> I wanted to dive a bit deeper into one aspect of the design of our
> *frontend driver*, `flang-new -fc1`. It is intended as the main tool for
> Flang frontend developers and we should make sure that it meets our
> requirements. If not, perhaps we can identify how to make it work
> better? More specifically, does the current split into action and
> non-action options makes sense?
>
> Please note - this discussion does not involve the compiler driver,
> `flang-new`.
>
> # *Action vs non-action options*
> In the frontend driver, you can split options into two groups:
>      * action options (e.g. `-emit-llvm`)
>      * non-action options (feature/configuration flags, e.g. `-ffixed-form`)
> Action options specify "what" the compiler will do, e.g. "parse the
> input file and lower it to LLVM IR" for `-emit-llvm`. Non-action options
> allow users to configure the frontend to behave in a certain way, e.g.
> treat all input files as fixed-form, regardless of the file extension.
> Another example for the latter is `-Werror` - make all warnings into
> errors. This tells the compiler "how" the deal with certain scenarios,
> but does not specify "what" to do.
>
> AFAIK, this design is consistent with `clang -cc1`.
>
> # *Default action*
> The frontend driver will run `-fsyntax-only` by default, i.e. the
> following two invocations are identical:
>
> ```lang=bash
> $ flang-new -fc1 input.f95
> $ flang-new -fc1 -fsyntax-only input.f95
> ```
>
> If users want a different action to be run, they need to specify it
> explicitly, e.g.
>
> ```lang=bash
> $ flang-new -fc1 -fdebug-unparse input.f95
> ```
>
> This behaviour is consistent with `clang -cc1`.
>
> # *Selected Implementation Details*
> For every action flag, there's a dedicated specialisation of the
> `FrontendActions` class in FrontendActions.h [1]. Right now, the only
> way to identify which flag is an action flag, is to look up the
> implementation. For example, options decorated with `Action_Group` in
> Options.td [2] are action flags. Alternatively, you can check the switch
> statements in CompilerInvocation.cpp [3] that selects the frontend
> action based on the input flags.
>
> # *One action at a time*
> The frontend driver will only run the rightmost frontend action
> specified on the command line. This is illustrated below:
>
> ```lang=bash
> # Runs -fdebug-unparse, -fdebug-pre-fir-tree is ignored
> $ flang-new -fc1 -fdebug-pre-fir-tree -fdebug-unparse input.f95
> # Runs -fdebug-pre-fir-tree, -fdebug-unparse is ignored
> $ flang-new -fc1 -fdebug-unparse  -fdebug-pre-fir-tree input.f95
> ```
>
> This approach means that the design is relatively simple. Allowing
> multiple actions per invocation would require the driver to schedule and
> to keep track of the requested actions. That would complicate the
> implementation.
>
> `flang-new -fc1` does not warn about action flags being ignored. This is
> counter-intuitive, but I wasn't able to identify an easy fix for this.
> We've recently discussed this in Bugzilla [4].
>
> AFAIK, this behaviour is consistent with `clang -cc1`.
>
> # *Does this work for you*?
>
> With the "one action at a time" rule, it is crucial to make sure that
> the split into action and non-action options is optimal. So far we have
> used a few heuristics:
> * if a flag requires something unique to happen, it's an action (e.g.
> `-fdebug-unparse` requires a call to `Fortran::parser::Unparse` that's
> otherwise not required)
> * if something is an action in `clang -cc1`, it should also be an action
> in `flang-new -fc1` (e.g. `-emit-llvm`)
> * if a flag configures some state, it's not an action (e.g. `-ffixed-form`)
>
> To make this a bit easier to visualise, I've compiled the list of
> options in `flang-new -fc1` in a spreadsheet [5]. I've also added
> actions options from `clang -cc1` for comparison. Note that out of ~820
> options in `clang -cc1` (extracted from `clang -cc1 -help`), only 36 are
> action options.
>
> Note: I've tried to make my spreadsheet [5] as accurate as possible, but
> wasn't able to generate it automatically and might have missed something.
>
> So, does the current split make sense to you? Should any of the options
> be re-implemented? I may not have the time to implement the suggested
> changes myself, but will be available to help you and to review your
> patches. And I will also be adding more documentation upstream. In fact,
> first patch is already available [6].
>
> Thank you for taking a look!
> -Andrzej
>
>
> [1]
> https://github.com/llvm/llvm-project/blob/main/flang/include/flang/Frontend/FrontendActions.h
> [2]
> https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Driver/Options.td
> [3]
> https://github.com/llvm/llvm-project/blob/main/flang/lib/Frontend/CompilerInvocation.cpp#L111-L178
> [4] https://bugs.llvm.org/show_bug.cgi?id=52095
> [5]
> https://docs.google.com/spreadsheets/d/1Cbzv58m_bO439sCRa4-onhhi-3JdFnLAhhTkeCMDdD4/edit?usp=sharing
> [6] https://reviews.llvm.org/D111573
> _______________________________________________
> flang-dev mailing list
> flang-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev