Re: [llvm-dev] Is there precedent for customizing clang -help output in a toolchain specific way

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Is there precedent for customizing clang -help output in a toolchain specific way

Hubert Tong via cfe-dev

Hi Andrzej,

I've been playing around with a couple of approaches to allow a toolchain to take control of the content of the -help output, but I'm not thrilled with the results.

The general approach that I've tried is to have a toolchain-specific version of PrintHelp() create its own OptTable either by filtering the OptTable generated from Options.td or by using a toolchain-specific version of Options.td that contains only the options and HelpText fields that the toolchain wants in the -help output. Each of these approaches has to mess with a generic API in some way (either the OptTable API or the Driver API).

Have you had some success in your attempts to customize Driver::PrintHelp()? I'd be interested to learn what you've tried.

~ Todd

-----Original Message-----
From: llvm-dev [mailto:[hidden email]] On Behalf Of Andrzej Warzynski via llvm-dev
Sent: Monday, July 27, 2020 3:53 AM
To: [hidden email]; '[hidden email]'
Subject: [EXTERNAL] Re: [llvm-dev] Is there precedent for customizing clang -help output in a toolchain specific way

[+ cfe-dev]

Hi Todd,

We're currently trying to solve a similar problem for Flang [1]. From
what we have seen so far,

* Options.td
* the only instance of DriverOptTable [2]
* the ID enum from clang/include/clang/Driver/Options.h [3]

are tightly coupled together and hence it is tricky to pick and choose
what you want.

There's also getIncludeExcludeOptionFlagMasks in
clang/lib/Driver/Driver.cpp [4], but I'm confused about the meaning of
IncludedFlagsBitmask and ExcludedFlagsBitmask. We did experiment with
that, but that made libclangDriver quite unhappy (things started to
break in an unexpected way).

Perhaps somebody on cfe-dev (CC'ed) would have some hints? In the
meantime we've also been customising Driver::PrintHelp().

-Andrzej


[1] http://lists.llvm.org/pipermail/llvm-dev/2020-June/141994.html
[2]
https://github.com/llvm/llvm-project/blob/2c1799f8928e1a63020fa8099d254c084f8be2f2/clang/lib/Driver/DriverOptions.cpp#L43
[3]
https://github.com/llvm/llvm-project/blob/2c1799f8928e1a63020fa8099d254c084f8be2f2/clang/include/clang/Driver/Options.h#L39
[4]
https://github.com/llvm/llvm-project/blob/2c1799f8928e1a63020fa8099d254c084f8be2f2/clang/include/clang/Driver/Options.h#L26


On 24/07/2020 20:36, Snider, Todd via llvm-dev wrote:

> Hi All,
>
> I am looking to customize the -help display for a downstream clang port
> as many options defined in Options.td are not applicable to the
> processor family I�m targeting and several applicable options do not
> have HelpText.
>
> I�ve considered adding a toolchain specific hook in the vicinity of
> Driver::PrintHelp(), but I�d rather avoid adding a hook if there is a
> better solution that already exists.
>
> Is there a best practice for enabling a toolchain to control the output
> of the clang �help option?
>
> ~ Todd Snider
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Is there precedent for customizing clang -help output in a toolchain specific way

Hubert Tong via cfe-dev
Hey Todd,

Sadly I've not had the bandwidth to look into this more. I've simply
tweaked PrintHelp() via clang::driver::options::ClangFlangs (I added an
extra flag for Flang). The other options (i.e. irrelevant for Flang) are
always there (i.e. present in OptTable) - we only control what's
displayed via `-help`. Perhaps this is _the canonical_ solution to this?
IIUC, that's what you've tried to begin with.

I share your observation - anything more sound (e.g. constructing
customized OptTable) requires non-trivial refactoring. However, I've
noticed that parsing of command line options is already quite optimised
and I'm not convinced that trimming OptTable would be beneficial. But
I'd have to dive a bit deeper into this.

I've recently shared our updated plan for the Flang driver on cfe-dev
[1]. There's a section on options too, though it's more or less what we
discussed here already. Tl;Dr We'd like to refactor libclangDriver a
bit, but that's excluding the toolchain options.

-Andrzej

[1] http://lists.llvm.org/pipermail/cfe-dev/2020-July/066393.html

On 05/08/2020 16:26, Snider, Todd wrote:

>
> Hi Andrzej,
>
> I've been playing around with a couple of approaches to allow a toolchain to take control of the content of the -help output, but I'm not thrilled with the results.
>
> The general approach that I've tried is to have a toolchain-specific version of PrintHelp() create its own OptTable either by filtering the OptTable generated from Options.td or by using a toolchain-specific version of Options.td that contains only the options and HelpText fields that the toolchain wants in the -help output. Each of these approaches has to mess with a generic API in some way (either the OptTable API or the Driver API).
>
> Have you had some success in your attempts to customize Driver::PrintHelp()? I'd be interested to learn what you've tried.
>
> ~ Todd
>
> -----Original Message-----
> From: llvm-dev [mailto:[hidden email]] On Behalf Of Andrzej Warzynski via llvm-dev
> Sent: Monday, July 27, 2020 3:53 AM
> To: [hidden email]; '[hidden email]'
> Subject: [EXTERNAL] Re: [llvm-dev] Is there precedent for customizing clang -help output in a toolchain specific way
>
> [+ cfe-dev]
>
> Hi Todd,
>
> We're currently trying to solve a similar problem for Flang [1]. From
> what we have seen so far,
>
> * Options.td
> * the only instance of DriverOptTable [2]
> * the ID enum from clang/include/clang/Driver/Options.h [3]
>
> are tightly coupled together and hence it is tricky to pick and choose
> what you want.
>
> There's also getIncludeExcludeOptionFlagMasks in
> clang/lib/Driver/Driver.cpp [4], but I'm confused about the meaning of
> IncludedFlagsBitmask and ExcludedFlagsBitmask. We did experiment with
> that, but that made libclangDriver quite unhappy (things started to
> break in an unexpected way).
>
> Perhaps somebody on cfe-dev (CC'ed) would have some hints? In the
> meantime we've also been customising Driver::PrintHelp().
>
> -Andrzej
>
>
> [1] http://lists.llvm.org/pipermail/llvm-dev/2020-June/141994.html
> [2]
> https://github.com/llvm/llvm-project/blob/2c1799f8928e1a63020fa8099d254c084f8be2f2/clang/lib/Driver/DriverOptions.cpp#L43
> [3]
> https://github.com/llvm/llvm-project/blob/2c1799f8928e1a63020fa8099d254c084f8be2f2/clang/include/clang/Driver/Options.h#L39
> [4]
> https://github.com/llvm/llvm-project/blob/2c1799f8928e1a63020fa8099d254c084f8be2f2/clang/include/clang/Driver/Options.h#L26
>
>
> On 24/07/2020 20:36, Snider, Todd via llvm-dev wrote:
>> Hi All,
>>
>> I am looking to customize the -help display for a downstream clang port
>> as many options defined in Options.td are not applicable to the
>> processor family I�m targeting and several applicable options do not
>> have HelpText.
>>
>> I�ve considered adding a toolchain specific hook in the vicinity of
>> Driver::PrintHelp(), but I�d rather avoid adding a hook if there is a
>> better solution that already exists.
>>
>> Is there a best practice for enabling a toolchain to control the output
>> of the clang �help option?
>>
>> ~ Todd Snider
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev