RFC: refactoring libclangDriver/libclangFrontend to share with Flang

Hi Andrzej,

Per below references …

[9] https://github.com/llvm/llvm-project/blob/cbb3571b0df5a0948602aa4d2b913b64270143ff/clang/include/clang/Driver/Options.h#L26

[10] https://github.com/llvm/llvm-project/blob/cbb3571b0df5a0948602aa4d2b913b64270143ff/clang/lib/Driver/Driver.cpp#L1559

[11] https://github.com/llvm/llvm-project/blob/cbb3571b0df5a0948602aa4d2b913b64270143ff/clang/lib/Driver/DriverOptions.cpp#L43

COMPILER DRIVER OPTIONS

To handle Flang options we propose to:

  • Use ClangFlags [9] to identify Flang options (we will add a dedicated

enum for Flang, e.g. FlangOption)

  • Tweak Driver::PrintHelp [10] to only display the appropriate options

depending on the driver mode

What about downstream compiler products that want to provide a more succinct –help output (clang –help will write 900+ lines to stdout)?

It seems like there should be a toolchain-specific way to filter the DriverOptTable further than driver mode and existing groups and flags.

  • Add new Flang options for libClangDriver to the main DriverOptTable

[11] table, perhaps via a separate *.td file

This would still emit a unified Options.inc file, yes?

As my immediate interest is in customizing the –help output in a toolchain specific way, I think there are (at least) two concerns:

  • Adding toolchain specific groups to the Options.inc output (maybe via a separate .td file like you suggest for flang)

  • A mechanism the toolchain can latch onto to filter the DriverOptTable in a toolchain specific way

o Would like to be able to provide a custom HelpText field and associate an option with a toolchain-specific group

o Maybe add mutable fields to the OptTable::Info that the toolchain can use to annotate the DriverOptTable?

I’m interested to learn what other downstream compiler products like armclang have done to solve this problem. Do they implement something entirely disjoint from the upstream code base? or do they use the OptTable infrastructure?

~ Todd Snider

Todd,

Thank you for your email!

At this stage we are only focusing on a relatively basic driver supporting a very small amount of options compared to Clang. Our main goal for now is to leverage libclangDriver without introducing the dependency on Clang. This means refactoring libclangDriver enough so that it can be moved to a dedicated subproject.

I agree that the way options are handled in libclangDriver could be a bit more sympathetic to customising the output of `-help`. Thank you for raising this! We feel that this could be improved at later time. Knowing that others face similar issue is re-assuring and will make any future refactoring worthwhile.

More comments inline.

What about downstream compiler products that want to provide a more succinct �help output (clang �help will write 900+ lines to stdout)?

In this RFC I only focus on the Flang driver (i.e. one specific customer of libclangDriver), which want to implement upstream.

It seems like there should be a toolchain-specific way to filter the DriverOptTable further than driver mode and existing groups and flags.

I agree, but this is out-of-scope of this RFC and what we want to achieve at this stage. We propose this as a future enhancement.

> * Add new Flang options for libClangDriver to the main DriverOptTable

[11] table, perhaps via a separate *.td file

This would still emit a unified Options.inc file, yes?

Correct, nothing changes in this respect.

As my immediate interest is in customizing the �help output in a toolchain specific way, I think there are (at least) two concerns:

I think that these concerns relate to how options are _currently_ handled in libclangDriver in general. We have no plans to change that in the near future. Instead, we want to leverage the current implementation and filter options in printHelp via option groups/flags.

I�m interested to learn what other downstream compiler products like armclang have done to solve this problem.

In armclang that I'm familiar with (AFAIK, there's more than 1), filtering is done at the printHelp level via option groups (i.e. similarly that what we intend to use for Flang).
-Andrzej

Hi Andrzej,

Thanks for the quick response.

I realize that customization of the DriverOptTable is not quite in the scope of your RFC, but regarding ...

I�m interested to learn what other downstream compiler products like
armclang have done to solve this problem.

In armclang that I'm familiar with (AFAIK, there's more than 1),
filtering is done at the printHelp level via option groups (i.e.
similarly that what we intend to use for Flang).

It sounds like the armclang solution might freely be adding to/editing the Options.td file (special group filter + custom HelpText fields), yes?

If that is the case, it is not something that would likely be upstreamed.

Is there someone familiar with how armclang implements a custom help display that could provide more details?

~ Todd