[flang-dev] [RFC] Frontend driver: action vs non-action options
Andrzej Warzynski via flang-dev
flang-dev at lists.llvm.org
Tue Oct 19 07:55:24 PDT 2021
Some dump options require extra work that otherwise is not needed, e.g.
`-fdebug-measure-parse-tree` or `-fget-definition`. So I think that
these should remain as actions.
I guess that `-fdebug-dump-parse-tree` could be replaced with an option
flag that would make the compiler dump the parse tree in every action
that generates one. But what do we do with the option for specifying the
output (i.e. `-o`)? Currently, this prints to stdout:
flang-new -fc1 -emit-mlir input.f90 -o -
If `-fdebug-dump-parse-tree` is an option (rather than an action),
should everything be dumped to stdout in the following case?
flang-new -fc1 -emit-mlir -fdebug-dump-parse-tree input.f90 -o -
And should `flang-new -fc1` print everything to `output.o` in this case:
flang-new -fc1 -emit-mlir -fdebug-dump-parse-tree input.f90 -o output.o
I also played with `gfortran`. I didn't have much luck with their
frontend driver (`f951` ), so I focused on `gfortran` itself. The
following generates an object file *and* dumps the parse tree to stdout:
gfortran -fdump-parse-tree hello.f95
I believe that that's the behaviour that you'd like to see in
`flang-new`, Pete? I've noticed some other confusing behaviour with
Btw, I've also raised this issue with Clang folks:
On 14/10/2021 22:21, Peter Steinfeld wrote:
> Since we can only have one action option at a time, any option that might reasonably appear in combination with another option should not be an action option. As Michael noted, we have many dump options, and I personally use them routinely in various combinations. This, to me, argues that none of them should be action options.
> Things in the compiler proceed in a linear series of operations -- preprocessing, parsing, semantic analysis, code generation. It make sense to me to have the options that control this sequence to be action options. I would think that everything else would be flag options.
> I agree with Michael that conflicting options should produce error messages. I think that this should apply to options generally, not just action options.
> -----Original Message-----
> From: flang-dev <flang-dev-bounces at lists.llvm.org> On Behalf Of Andrzej Warzynski via flang-dev
> Sent: Thursday, October 14, 2021 5:27 AM
> To: Michael Kruse <llvm at meinersbur.de>
> Cc: via flang-dev <flang-dev at lists.llvm.org>
> Subject: Re: [flang-dev] [RFC] Frontend driver: action vs non-action options
> External email: Use caution opening links or attachments
> Michael, that's a very re-assuring reply, thank you! Also, these are very helpful and much appreciated suggestions.
> On 13/10/2021 19:32, Michael Kruse wrote:
>> IMHO the compiler should error-out if multiple (different) actions are
> Here's my naive attempt to implement this behaviour:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD111781&data=04%7C01%7Cpsteinfeld%40nvidia.com%7C24f996a3c85740e4e4d708d98f0e0968%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637698112733879280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2F7QO4rL1vlH%2FODd2bJa%2BsWMnmdye%2BRR7jHZRUsdZ%2FIg%3D&reserved=0. This extends the ArgList API rather than the TableGen logic. It has its limitations, so I'm not sure whether that's the right approach.
> I really like your idea of `-fdump=unparse,symbols -o dump.txt`. It would nicely extend the current approach, so might be the easiest path towards more flexible "dumping" options.
>> 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?
>> 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,
>>> # *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:
>>> $ 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.
>>> $ 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 . 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  are action flags. Alternatively, you can check the
>>> switch statements in CompilerInvocation.cpp  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:
>>> # 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
>>> `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 .
>>> 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.
>>> To make this a bit easier to visualise, I've compiled the list of
>>> options in `flang-new -fc1` in a spreadsheet . 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  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 .
>>> Thank you for taking a look!
>>> pilerInvocation.cpp#L111-L178 
>>> nLAhhTkeCMDdD4/edit?usp=sharing 
>>> flang-dev mailing list
>>> flang-dev at lists.llvm.org
> flang-dev mailing list
> flang-dev at lists.llvm.org
More information about the flang-dev