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.
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 . 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.