Snider, Todd via llvm-dev
2020-Aug-05 15:26 UTC
[llvm-dev] Is there precedent for customizing clang -help output in a toolchain specific way
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:llvm-dev-bounces at lists.llvm.org] On Behalf Of Andrzej Warzynski via llvm-dev Sent: Monday, July 27, 2020 3:53 AM To: llvm-dev at lists.llvm.org; 'cfe-dev at lists.llvm.org' 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 > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >_______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Andrzej Warzynski via llvm-dev
2020-Aug-06 19:44 UTC
[llvm-dev] Is there precedent for customizing clang -help output in a toolchain specific way
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:llvm-dev-bounces at lists.llvm.org] On Behalf Of Andrzej Warzynski via llvm-dev > Sent: Monday, July 27, 2020 3:53 AM > To: llvm-dev at lists.llvm.org; 'cfe-dev at lists.llvm.org' > 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 >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >