<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
span.EmailStyle19
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;
        mso-fareast-language:EN-US;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-CA" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<p class="MsoNormal">The API benefits sound nice, though presumably some could be retrofitted to cl::opt if that was the only goal. Side benefits in addition to removing global ctors are nice to have.<br>
 <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:11.55pt">The drawback is some initial boilerplate (e.g. llvm-tblgen -gen-opt-parser-defs in CMakeLists.txt, class NmOptTable in code).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:11.55pt">The handling of comma separated options -arch=x86_64,arm64 doesn't have direct OptTable support. llvm::SplitString is needed (just search for SplitString in <a href="https://reviews.llvm.org/D105330" target="_blank">https://reviews.llvm.org/D105330</a>)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:11.55pt">But this doesn't tend to increase complexity because the cl::list<std::string> will need per-value verification anyway.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:11.55pt"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:11.55pt">One potential one (though I don't recall it being discussed recently) would be that maybe this addresses the issue of global ctors in cl::opt? Does OptTable avoid/not use global constructors? That would be nice
 - it's an ongoing issue that LLVM library users pay for command line argument support they have no need for in the form of global ctor execution time.<o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:11.55pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:11.55pt">OptTable is used as a local variable. So yes, it avoids global constructors,
<o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:11.55pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:11.55pt">Nice :)<o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:11.55pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:11.55pt">Note that MLIR is using cl::opt without global ctor (we build with `-Werror=global-constructors`).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:11.55pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:11.55pt">The pattern we use to write a tool with cl::opt and avoid global ctor (and can be used to avoid collision) looks like: <a href="https://github.com/llvm/llvm-project/blob/main/mlir/lib/IR/MLIRContext.cpp#L57-L83">https://github.com/llvm/llvm-project/blob/main/mlir/lib/IR/MLIRContext.cpp#L57-L83</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:11.55pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:11.55pt">The tool that wants to expose the MLIRContext options to the command line calls registerMLIRContextCLOptions() before parsing the command line.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:11.55pt">Wouldn't this translate directly to LLVM tools as well with some minor refactoring?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:11.55pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:11.55pt">The same applies to all of the infrastructure in MLIR, passes are registered explicitly, etc. This decouples the "is this code linked in" from "options are loaded" annoying part of the global constructors.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:11.55pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:11.55pt">-- <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:11.55pt">Mehdi<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b><i>[Alexandre Ganea] </i></b>I think one other issue with cl::opt is that it aggregates the “command-line argument definition” and the “runtime parameter”
<i>de facto</i> in a single object (unless cl::location is manually specified to every cl::opt). What MLIR does solves the issue mentioned by David, the fact that every tool pulls/initializes every cl::opt out there. However OptTable solves both problems, and
 makes the entry point thread-safe.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>