<div dir="ltr"><div dir="ltr">Thanks James for the pointer - I'm still amazed by LLVM's pandora box colloquially named tablegen!</div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 10, 2019 at 11:33 AM James Henderson <<a href="mailto:jh7370.2008@my.bristol.ac.uk">jh7370.2008@my.bristol.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Serge,</div><div><br></div><div>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).</div><div><br></div><div>James<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 9 May 2019 at 17:24, Serge Guelton via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi folks,<br>
<br>
today, I wanted to concatenate two .ll, and naively typed:<br>
<br>
$ llvm-cat -help<br>
<br>
This is the not-so-helpful output I had:<br>
<br>
OVERVIEW: Module concatenation<br>
USAGE: llvm-cat [options] <input files><br>
<br>
OPTIONS:<br>
<br>
General options:<br>
<br>
-aarch64-neon-syntax - Choose style of NEON code to emit from AArch64 backend:<br>
=generic - Emit generic NEON assembly<br>
=apple - Emit Apple-style NEON assembly<br>
-amdgpu-dump-hsa-metadata - Dump AMDGPU HSA Metadata<br>
-amdgpu-enable-merge-m0 - Merge and hoist M0 initializations<br>
-amdgpu-sdwa-peephole - Enable SDWA peepholer<br>
[...]<br>
<br>
Surely, the style of NEON code to emit from AArch64 backend is not the information I was looking for...<br>
<br>
I've implemented a straight-forward patch for llvm-cat here <a href="https://reviews.llvm.org/D61740" rel="noreferrer" target="_blank">https://reviews.llvm.org/D61740</a>, and the result becomes:<br>
<br>
OVERVIEW: Module concatenation<br>
USAGE: llvm-cat [options] <input files><br>
<br>
OPTIONS:<br>
<br>
Generic Options:<br>
<br>
--help - Display available options (--help-hidden for more)<br>
--help-list - Display list of available options (--help-list-hidden for more)<br>
--version - Display the version of this program<br>
<br>
llvm-cat Options:<br>
<br>
-b - Whether to perform binary concatenation<br>
-o=<filename> - Output filename<br>
<br>
<br>
Depending on the tools, the filtering imposed by llvm::cl::HideUnrelatedOptions may be too harsh, but there's still -help-hidden for the curious!<br>
<br>
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?<br>
<br>
++<br>
Serge<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>