[cfe-dev] [EXTERNAL] Re: RFC: refactoring libclangDriver/libclangFrontend to share with Flang
Snider, Todd via cfe-dev
cfe-dev at lists.llvm.org
Mon Aug 10 06:34:19 PDT 2020
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?
From: Andrzej Warzynski [mailto:andrzej.warzynski at arm.com]
Sent: Friday, August 7, 2020 10:55 AM
To: Snider, Todd
Cc: 'cfe-dev at lists.llvm.org'
Subject: [EXTERNAL] Re: [cfe-dev] RFC: refactoring libclangDriver/libclangFrontend to share with Flang
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
More comments inline.
On 06/08/2020 18:14, Snider, Todd wrote:
> 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
>  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).
More information about the cfe-dev