[llvm-dev] Making llvm-xyz -help useful
James Henderson via llvm-dev
llvm-dev at lists.llvm.org
Fri May 10 02:33:10 PDT 2019
Hi Serge,
I'm all for any approach that hides irrelevant options from the individual
tools. This is one method. Another method might be to switch to using
tablegen, like we do with LLD or llvm-objcopy, which will have other
benefits too relating to command-line option handling. However, it is
important that we don't lose options that ARE relevant to the tool by any
such switch. I cannot comment on which options those are for some tools,
but at least for the tools that I've been working on recently, I'm happy to
review (and indeed have done for some in the past).
James
On Thu, 9 May 2019 at 17:24, Serge Guelton via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi folks,
>
> today, I wanted to concatenate two .ll, and naively typed:
>
> $ llvm-cat -help
>
> This is the not-so-helpful output I had:
>
> OVERVIEW: Module concatenation
> USAGE: llvm-cat [options] <input files>
>
> OPTIONS:
>
> General options:
>
> -aarch64-neon-syntax - Choose style of
> NEON code to emit from AArch64 backend:
> =generic - Emit generic
> NEON assembly
> =apple - Emit
> Apple-style NEON assembly
> -amdgpu-dump-hsa-metadata - Dump AMDGPU HSA
> Metadata
> -amdgpu-enable-merge-m0 - Merge and hoist
> M0 initializations
> -amdgpu-sdwa-peephole - Enable SDWA
> peepholer
> [...]
>
> Surely, the style of NEON code to emit from AArch64 backend is not the
> information I was looking for...
>
> I've implemented a straight-forward patch for llvm-cat here
> https://reviews.llvm.org/D61740, and the result becomes:
>
> OVERVIEW: Module concatenation
> USAGE: llvm-cat [options] <input files>
>
> OPTIONS:
>
> Generic Options:
>
> --help - Display available options (--help-hidden for more)
> --help-list - Display list of available options
> (--help-list-hidden for more)
> --version - Display the version of this program
>
> llvm-cat Options:
>
> -b - Whether to perform binary concatenation
> -o=<filename> - Output filename
>
>
> Depending on the tools, the filtering imposed by
> llvm::cl::HideUnrelatedOptions may be too harsh, but there's still
> -help-hidden for the curious!
>
> Any thoughts on that approach? Should I go on that way for other tools? If
> so, anyone willing to be auto-added as a reviewer?
>
> ++
> Serge
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190510/02c641ac/attachment.html>
More information about the llvm-dev
mailing list