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
James Henderson via llvm-dev
2019-May-10 09:33 UTC
[llvm-dev] Making llvm-xyz -help useful
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>
Thanks James for the pointer - I'm still amazed by LLVM's pandora box colloquially named tablegen! You're pointing at a right problem, which is independent of the actual engine used to specify tool options: To what extent are the options of liked libraries relevant to the tool. And only tool maintainer can answer that question, so a per-tool approach is probably the better option here. On Fri, May 10, 2019 at 11:33 AM James Henderson < jh7370.2008 at my.bristol.ac.uk> wrote:> 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/20190511/acc2e1c5/attachment.html>
Unrelated to your actual question, but why are we linking targets into llvm-cat? -Chris> On May 9, 2019, at 9:23 AM, 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
Chris, I don't see this locally, so I don't think we are. However, if you specify -DLLVM_LINK_LLVM_DYLIB CMake links the tools against libLLVM instead of the component libraries, which would result in this behavior. -Chris> On May 12, 2019, at 9:14 AM, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Unrelated to your actual question, but why are we linking targets into llvm-cat? > > -Chris > >> On May 9, 2019, at 9:23 AM, 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 > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev