Making llvm-xyz -help useful

Project Infrastructure LLVM Dev List Archives
1

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 ⚙ D61740 Simplify llvm-cat -help, 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?

2

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

3

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.

4

Unrelated to your actual question, but why are we linking targets into llvm-cat?

-Chris

5

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