<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 24 May 2019 at 04:44, Ben Craig &lt;<a href="mailto:ben.craig@ni.com">ben.craig@ni.com</a>&gt; 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 lang="EN-US">
<div dir="auto" style="direction:ltr;margin:0px;padding:0px;font-family:sans-serif;font-size:11pt;color:black">
What are the current restrictions with regards to static libraries and link time optimization? Do those restrictions also apply to modules and link time optimizations?<br>
<br>
</div>
<div dir="auto" style="direction:ltr;margin:0px;padding:0px;font-family:sans-serif;font-size:11pt;color:black">
<span id="gmail-m_-2850665111925190425OutlookSignature">
<div dir="auto" style="direction:ltr;margin:0px;padding:0px;font-family:sans-serif;font-size:11pt;color:black">
Get <a href="https://aka.ms/ghei36" target="_blank">Outlook for Android</a></div>
</span><br>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-2850665111925190425divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> <a href="mailto:tooling-bounces@open-std.org" target="_blank">tooling-bounces@open-std.org</a> &lt;<a href="mailto:tooling-bounces@open-std.org" target="_blank">tooling-bounces@open-std.org</a>&gt; on behalf of Olga Arkhipova &lt;<a href="mailto:olgaark@microsoft.com" target="_blank">olgaark@microsoft.com</a>&gt;<br>
<b>Sent:</b> Thursday, May 23, 2019 7:30:57 PM<br>
<b>To:</b> <a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a>; Gabriel Dos Reis; Anna Gringauze; Lukasz Mendakiewicz; Cameron DaCamara<br>
<b>Subject:</b> [EXTERNAL] [Tooling] BMI distribution and reading BMI data</font>
<div> </div>
</div>
<div>
<div class="gmail-m_-2850665111925190425WordSection1">
<p class="MsoNormal">Hi all,</p>
<p class="MsoNormal">I’d like to discuss the BMI usage and distribution topics – can we do on tomorrow’s  SG15 meeting? Or later?</p>
<p class="MsoNormal">Thanks,</p>
<p class="MsoNormal">Olga</p>
<p class="MsoNormal"><b> </b></p>
<p class="MsoNormal"><b> </b></p>
<p class="MsoNormal"><b>BMI distribution</b></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Currently, built modules (BMI) are very similar to static libraries from build perspective:</p>
<p class="MsoNormal" style="margin-left:27pt;vertical-align:middle">
<span>1.<span style="font:7pt &quot;Times New Roman&quot;">       </span></span>They are specific to the compiler version (i.e. can only be used by the compiler binary compatible with the one which produced them)</p>
<p class="MsoNormal" style="margin-left:27pt;vertical-align:middle">
<span>2.<span style="font:7pt &quot;Times New Roman&quot;">       </span></span>If they depend on other modules, their BMIs need to be present too for successful build.</p>
<p class="MsoNormal" style="margin-left:27pt;vertical-align:middle">
<span>3.<span style="font:7pt &quot;Times New Roman&quot;">       </span></span>A number of compiler switches which were used to build the module should match the compiler switches for the source which uses this module.
</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">So distribution of BMIs currently has similar limitations as the distribution of built static libraries:</p>
<p class="MsoNormal" style="margin-left:27pt;vertical-align:middle">
<span style="font-size:10pt;font-family:Symbol"><span>·<span style="font:7pt &quot;Times New Roman&quot;">      
</span></span></span>has strict requirements on the compiler and other used libraries versions</p>
<p class="MsoNormal" style="margin-left:27pt;vertical-align:middle">
<span style="font-size:10pt;font-family:Symbol"><span>·<span style="font:7pt &quot;Times New Roman&quot;">      
</span></span></span>limited to the platforms, architectures and #defines it is built for.</p>
<p class="MsoNormal" style="margin-left:27pt"> </p>
<p class="MsoNormal">The BMI distribution definitely has performance advantage for the builds which meet all restrictions and requirements, i.e. the same ones which can use built static libraries.</p></div></div></div></blockquote><div><br></div><div>Only for the first build</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div><div class="gmail-m_-2850665111925190425WordSection1">
<p class="MsoNormal"> </p>
<p class="MsoNormal">If BMI&#39;s restriction of the specific compiler and exact command line can be weakened somehow, or at least some data can be extracted from all BMIs, the performance advantage of the BMI distribution can be wider.</p></div></div></div></blockquote><div><br></div><div>I really do not think that we should make any effort to ease the portability of BMI - this opens to more ODR and ABI issues that we already have</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div><div class="gmail-m_-2850665111925190425WordSection1">
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b>Scenarios where extracting at least some data from BMIs is needed</b></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">VS instellisense (EDG)</p>
<p class="MsoNormal" style="margin-left:27pt">Visual Studio and VS Code support not only MSVC, but also clang and gcc.</p>
<p class="MsoNormal" style="margin-left:27pt">VS is using EDG compiler as intellisense engine, which currently supports MSVC, Clang and gcc modes. As performance of EDG compilation is very critical, ideally, EDG should be able to use modules already built
 by MSVC, clang and gcc.</p></div></div></div></blockquote><div><br></div><div>Isn&#39;t that  brittle? - all these compilers may change their modules format (and do so) at any time. how will edg keep up ?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div><div class="gmail-m_-2850665111925190425WordSection1"><p class="MsoNormal" style="margin-left:27pt"> </p>
<p class="MsoNormal" style="margin-left:27pt"> </p>
<p class="MsoNormal" style="margin-left:27pt">Linters (as-you-type code analysis) require
<span style="background:white">additional data specified in the source (annotations, pragmas, attributes, contracts). Ideally, this information should be always be present in BMI, independent on whether the code has been compiled for analysis or code generation.</span></p>
<p class="MsoNormal" style="margin-left:0.75in;vertical-align:middle">
<span style="font-size:10pt;font-family:&quot;Courier New&quot;;color:black"><span>o<span style="font:7pt &quot;Times New Roman&quot;">  
</span></span></span><span style="color:black;background:white">Alternative: producing a new BMI for linters and IntelliSense, making it slower.</span><span style="color:black"></span></p>
<p class="MsoNormal" style="margin-left:27pt"> </p>
<p class="MsoNormal" style="margin-left:27pt">Note: MSVC will have an option to include the original input source (not TU-expanded) into the IFCs.</p>
<p class="MsoNormal" style="margin-left:27pt"> </p>
<p class="MsoNormal">Clang-cl and clang-gcc</p>
<p class="MsoNormal" style="margin-left:27pt">Currently, clang-cl is (almost) ABI compatible with cl. I believe the same is true for clang and gcc.
</p>
<p class="MsoNormal" style="margin-left:27pt">Should Clang-cl be able to use modules produced by MSVC and vice versa?</p></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div><div class="gmail-m_-2850665111925190425WordSection1"><p class="MsoNormal" style="margin-left:27pt">
</p>
<p class="MsoNormal" style="margin-left:27pt">Should Clang-gcc be able to use modules produced by gcc and vice versa?</p></div></div></div></blockquote><div><br></div><div>Very personal opinion: no. Modules were designed to be transient build artifacts.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div><div class="gmail-m_-2850665111925190425WordSection1">
<p class="MsoNormal" style="margin-left:27pt"> </p>
<p class="MsoNormal">Build systems</p>
<p class="MsoNormal" style="margin-left:27pt">If BMIs are distributed together with their sources (like modules for MS standard libs) build systems might want to check if the available BMIs are actually compatible with the current build settings and if not,
 produce a different BMI from the source</p></div></div></div></blockquote><div><br></div><div>I have a question about Microsoft plans. There are a few compilation flags routinely used whether optimization levels, threading, debug,  iterator debug and so forth.</div><div>that could really easily lead to 64 or a lot more different configurations. Does Microsoft plans to ship a set of modules for each ?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div><div class="gmail-m_-2850665111925190425WordSection1">
<p class="MsoNormal"><span style="color:black"> </span></p>
<p class="MsoNormal"><span style="color:black;background:white">Static analysis (background code analysis, code analysis at build)</span><span style="color:black"></span></p>
<p class="MsoNormal" style="margin-left:27pt">Static analysis often requires additional data computed from the source which is normally not stored in the BMI. Such additional information is produced by static analysis tools during a separate analysis phase
 of the module and needs to be stored into a different BMI file. </p>
<p class="MsoNormal" style="margin-left:0.75in;vertical-align:middle">
<span style="font-size:10pt;font-family:&quot;Courier New&quot;"><span>o<span style="font:7pt &quot;Times New Roman&quot;">  
</span></span></span>Alternative 1: Always adding extra info which is not always needed is an unjustifiable performance expense.
</p>
<p class="MsoNormal" style="margin-left:0.75in;vertical-align:middle">
<span style="font-size:10pt;font-family:&quot;Courier New&quot;"><span>o<span style="font:7pt &quot;Times New Roman&quot;">  
</span></span></span>Alternative 2: Adding this information to already created BMI file creates build system complications.
</p>
<p class="MsoNormal" style="margin-left:27pt">The format of additional information is not defined at this point – the tools decide how to read and write the data. We recommend storing the data in a way that can be consumed by other tools and compilers.</p>
<p class="MsoNormal" style="margin-left:27pt"> </p>
<p class="MsoNormal" style="margin-left:27pt"> </p>
<p class="MsoNormal">Other scenarios?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b>BMI data to extract</b></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">At minimum, the following data should be extractable from any BMI</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal" style="margin-left:27pt;vertical-align:middle">
<span style="font-size:10pt;font-family:Symbol"><span>·<span style="font:7pt &quot;Times New Roman&quot;">      
</span></span></span>Module source file name/location (as it was during the module build)</p>
<p class="MsoNormal" style="margin-left:27pt;vertical-align:middle">
<span style="font-size:10pt;font-family:Symbol"><span>·<span style="font:7pt &quot;Times New Roman&quot;">      
</span></span></span>Compilation options used to build BMI, especially the ones which have to match in the source using this module (#defines, etc.)</p>
<p class="MsoNormal" style="margin-left:27pt;vertical-align:middle">
<span style="font-size:10pt;font-family:Symbol"><span>·<span style="font:7pt &quot;Times New Roman&quot;">      
</span></span></span>Referenced modules and their BMIs (unless included into compilation options)</p>
<p class="MsoNormal" style="margin-left:27pt;vertical-align:middle">
<span style="font-size:10pt;font-family:Symbol"><span>·<span style="font:7pt &quot;Times New Roman&quot;">      
</span></span></span>Static analysis data</p>
<p class="MsoNormal" style="margin-left:0.75in;vertical-align:middle">
<span style="font-size:10pt;font-family:&quot;Courier New&quot;"><span>o<span style="font:7pt &quot;Times New Roman&quot;">  
</span></span></span>Imported header units and the referenced header</p>
<p class="MsoNormal" style="margin-left:0.75in;vertical-align:middle">
<span style="font-size:10pt;font-family:&quot;Courier New&quot;"><span>o<span style="font:7pt &quot;Times New Roman&quot;">  
</span></span></span>Additional information stored by static analysis tools</p>
<p class="MsoNormal" style="margin-left:0.75in;vertical-align:middle">
<span style="font-size:10pt;font-family:&quot;Courier New&quot;"><span>o<span style="font:7pt &quot;Times New Roman&quot;">  
</span></span></span>Anything that is possible to extract from header files using a compiler frontend – i.e. types, symbols, ASTs, source information, annotations (declspecs), pragmas, attributes, etc (for consumption by code analysis)</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Should we encourage the compiler vendors to provide a way to do this for the BMIs they produce?</p></div></div></div></blockquote><div><br></div><div><br></div><div>I think there should be a separate, non-compiler dependent - agreed upon - stable format for static analysis and completion purposes. </div><div>Gabriel and Bjarne&#39;s IPR seem to be an interesting area to explore.</div><div><br></div><div>Regards,</div><div>Corentin</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div><div class="gmail-m_-2850665111925190425WordSection1">
<p class="MsoNormal"> </p>
</div>
</div>
</div>

_______________________________________________<br>
Tooling mailing list<br>
<a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/tooling" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><br>
</blockquote></div></div>