[cfe-dev] RFC: refactoring libclangDriver/libclangFrontend to share with Flang

Snider, Todd via cfe-dev cfe-dev at lists.llvm.org
Thu Aug 6 10:14:25 PDT 2020


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200806/b4488736/attachment.html>


More information about the cfe-dev mailing list