<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 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
        {font-family:"Trebuchet MS";
        panose-1:2 11 6 3 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
h1
        {mso-style-priority:9;
        mso-style-link:"Heading 1 Char";
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:24.0pt;
        font-family:"Times New Roman","serif";}
h2
        {mso-style-priority:9;
        mso-style-link:"Heading 2 Char";
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:18.0pt;
        font-family:"Times New Roman","serif";}
h4
        {mso-style-priority:9;
        mso-style-link:"Heading 4 Char";
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.apple-converted-space
        {mso-style-name:apple-converted-space;}
span.Heading1Char
        {mso-style-name:"Heading 1 Char";
        mso-style-priority:9;
        mso-style-link:"Heading 1";
        font-family:"Cambria","serif";
        color:#365F91;
        font-weight:bold;}
span.Heading2Char
        {mso-style-name:"Heading 2 Char";
        mso-style-priority:9;
        mso-style-link:"Heading 2";
        font-family:"Cambria","serif";
        color:#4F81BD;
        font-weight:bold;}
span.Heading4Char
        {mso-style-name:"Heading 4 Char";
        mso-style-priority:9;
        mso-style-link:"Heading 4";
        font-family:"Cambria","serif";
        color:#4F81BD;
        font-weight:bold;
        font-style:italic;}
span.EmailStyle21
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
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-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Mehdi,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>  Thank you for the explanation/confirmation. At this juncture timing in multithreaded mode is not the top issue for us as well, but at least I realize now that there is a general need for it, so if we can allocate any time on it I will bring it up for public discussion first.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>  Thank you again.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Sergei<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:Consolas;color:#1F497D'>---<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D'>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation</span><span style='font-size:10.5pt;font-family:Consolas;color:#1F497D'><o:p></o:p></span></p></div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> mehdi.amini@apple.com [mailto:mehdi.amini@apple.com] <br><b>Sent:</b> Monday, January 04, 2016 6:08 PM<br><b>To:</b> Sergei Larin<br><b>Cc:</b> Peter Collingbourne; llvm-dev; Teresa Johnson; Tobias Edler von Koch<br><b>Subject:</b> Re: Using -time-passes in LTO with splitting<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Hi,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>(re-sent to the correct llvm-dev)<o:p></o:p></p></div><div><p class=MsoNormal>Timing is definitively an issue in multithreaded mode (I think it is a known issue, but we may not have a PR opened yet). “Someone” needs to reimplement it I guess… <o:p></o:p></p><div><p class=MsoNormal>I just hasn’t been a high priority for anyone I think (and it won’t be for me in the next couple of months at least, but I’ll be happy to help on thinking about it and/or reviewing patches).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>About your comment on TSan, note that there are already some locks (for example in getNamedRegionTimer()). I wonder if the problem is about race condition or the way the timing are computed.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>— <o:p></o:p></p></div><div><p class=MsoNormal>Mehdi<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>On Jan 4, 2016, at 3:07 PM, Sergei Larin <<a href="mailto:slarin@codeaurora.org">slarin@codeaurora.org</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Peter,</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>  When you started work on parallel codegen – was it your (implicit) intent to have most basic compiler services available? It sounds like a generic question, but as I use parallel codegen more and more I see numerous issues with some things not being exactly thread safe… To be more specific I tried to time passes run in multiple threads using (-time-passes) and failed miserably.</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>  I guess my bigger question, and not only to you personally, do we have communal will to make sure that things like timing are working properly in multithread use mode?</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>  …if I miss some previous discussion on the topic, please forgive me and point me to the thread…</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks.</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Sergei</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>P. S.<span class=apple-converted-space> </span></span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thread sanitizer does not seem to get this as an issue.</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> <span class=apple-converted-space> </span></span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:Consolas;color:#1F497D'>---</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D'>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><div><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span class=apple-converted-space><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> </span></span><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'><a href="mailto:llvmdev-bounces@cs.uiuc.edu"><span style='color:purple'>llvmdev-bounces@cs.uiuc.edu</span></a><span class=apple-converted-space> </span>[<a href="mailto:llvmdev-bounces@cs.uiuc.edu"><span style='color:purple'>mailto:llvmdev-bounces@cs.uiuc.edu</span></a>]<span class=apple-converted-space> </span><b>On Behalf Of<span class=apple-converted-space> </span></b>Teresa Johnson<br><b>Sent:</b><span class=apple-converted-space> </span>Monday, August 03, 2015 2:00 PM<br><b>To:</b><span class=apple-converted-space> </span>Alex Rosenberg<br><b>Cc:</b><span class=apple-converted-space> </span><<a href="mailto:llvmdev@cs.uiuc.edu"><span style='color:purple'>llvmdev@cs.uiuc.edu</span></a>> List<br><b>Subject:</b><span class=apple-converted-space> </span>Re: [LLVMdev] RFC: ThinLTO File Format</span><o:p></o:p></p></div></div></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><div><p class=MsoNormal>Hi Alex,<o:p></o:p></p></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>After outlining some of the rationale for using native-wrapped, there were a couple of responses that indicated native-wrapped support was reasonable, but they preferred to see bitcode-only first (Phillip and Rafael). This is essentially what this proposal and the patches do - I've implemented some of the basic support for looking for and parsing the native-wrapped sections, but the bitcode-only reading/writing support is more complete.<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>In fact, as described in this RFC, I designed the native-wrapped format to utilize the same bitcode encoding for most of the ThinLTO information, so it uses most of the same underlying bitcode interfaces anyway. The additional support required for native-wrapped is not tremendous, and is similar to existing support in the LLVM tree for reading native-wrapped bitcode.<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>We believe that there will be clang/llvm users who will find native-wrapped ThinLTO easier to use for the same reasons (e.g. compatibility with existing native toolchains), so I don't expect this to be Google specific.<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>Thanks,<o:p></o:p></p></div></div><div><div><p class=MsoNormal>Teresa<o:p></o:p></p></div></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div><div><div><p class=MsoNormal>On Mon, Aug 3, 2015 at 12:26 PM, Alex Rosenberg <<a href="mailto:alexr@leftfield.org" target="_blank"><span style='color:purple'>alexr@leftfield.org</span></a>> wrote:<o:p></o:p></p></div><div><div><div><p class=MsoNormal>I think I've read all the feedback posted regarding your May proposal. I have yet to see a single response that wants native object wrapped bitcode.<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>If the only use for native object wrapped bitcode is for your project at Google, then it probably shouldn't go into the tree against all of these objections.<br><br>Alex<o:p></o:p></p></div></div><div><div><div><p class=MsoNormal style='margin-bottom:12.0pt'><br>On Aug 3, 2015, at 9:19 AM, Teresa Johnson <<a href="mailto:tejohnson@google.com" target="_blank"><span style='color:purple'>tejohnson@google.com</span></a>> wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal>As discussed in the high-level ThinLTO RFC <span style='font-size:9.5pt'>(</span><a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/086211.html" target="_blank"><span style='font-size:9.5pt;color:purple'>http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/086211.html</span></a><span style='font-size:9.5pt'>), we would like to add support for native object wrapped bitcode and ThinLTO information. Based on comments on the mailing list, I am adding support for ThinLTO in both normal bitcode files, as well as native-object wrapped bitcode.</span><o:p></o:p></p></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal><span style='font-size:9.5pt'>The following RFC describes the planned file format of ThinLTO information both in the bitcode-only and native object wrapped cases. It doesn't yet define the exact record format, as I would like feedback on the overall block design first.</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal><span style='font-size:9.5pt'>I've also implemented the support for reading and writing the bitcode blocks in the following patch:</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11722&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=oUy_PB_mSfRgDO7H7bZOR04gv_DMzX5rPO_lv4PHt60&s=WVxrKkHnjKr75fCQ-UkGke8dk6KpZcFCnLWVrJ3G188&e=" target="_blank"><span style='font-size:9.5pt;color:purple'>http://reviews.llvm.org/D11722</span></a><o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>The ThinLTO data structures and the file APIs are described in a separate RFC I will be sending simultaneously, with pointers to the patches implementing them.<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>Looking forward to your feedback. Thanks!<o:p></o:p></p></div></div><div><div><p class=MsoNormal>Teresa<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><p class=MsoNormal align=center style='text-align:center'><span style='font-size:21.0pt;font-family:"Trebuchet MS","sans-serif"'>ThinLTO File Format</span><o:p></o:p></p><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><p class=MsoNormal>Bitcode ThinLTO Support<br>    ThinLTO Bitcode Blocks<br>        THINLTO_SYMTAB_BLOCK<br>        THINLTO_MODULE_STRTAB_BLOCK<br>        THINLTO_FUNCTION_SUMMARY_BLOCK<br>    Bitcode Combined Function Summary<br>Native-Wrapped ThinLTO Support<br>    Native-wrapped bitcode<br>    Native-Wrapped Combined Function Summary<o:p></o:p></p></div></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-left:.25in'> <o:p></o:p></p><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>This document discusses the high-level file format used to represent ThinLTO function index/summary information. It covers the index created at the module level (produced by the phase-1 -c compiles) and the combined function index/summary generated by the phase-2 linker step of a ThinLTO compile. More information about ThinLTO compilation can be found in the Updated RFC at:<span class=apple-converted-space> </span></span><a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/086211.html" target="_blank"><span style='font-size:11.0pt;font-family:"Arial","sans-serif";color:purple'>http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/086211.html</span></a><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>As discussed in that document and subsequent mailing list discussions, we will add support for ThinLTO with both normal bitcode-only intermediate files, as well as native-wrapped bitcode files. This document describes the ThinLTO format for both of these file types. The formats were designed to allow as much sharing of APIs and implementation as possible between the two file types.</span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>The ThinLTO information is written to the per-module (translation unit) intermediate files during the phase-1 (-c) compile. They are read by the phase-2 linker step, which aggregates them into a combined function index/summary file, and which by default does not need to parse the rest of the module IR. The phase-3 parallel backend processes that each compile a single module into a final object file read the combined function index/summary file during importing, but do not need to look at the module’s own ThinLTO information.</span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>Since as noted above the usual normal non-ThinLTO module IR and its ThinLTO information are not typically needed in the same compile step, the following design tries to minimize the required parsing of the normal module bitcode IR when reading the ThinLTO information, and vice versa.</span><o:p></o:p></p></div><h1 style='margin-bottom:0in;margin-bottom:.0001pt'><span style='font-size:16.0pt;font-family:"Trebuchet MS","sans-serif";font-weight:normal'>Bitcode ThinLTO Support</span><o:p></o:p></h1><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>This section describes the representation of ThinLTO for bitcode-only intermediate files.<span class=apple-converted-space> </span></span><o:p></o:p></p></div><h2 style='margin-bottom:0in;margin-bottom:.0001pt'><span style='font-size:13.0pt;font-family:"Trebuchet MS","sans-serif"'>ThinLTO Bitcode Blocks</span><o:p></o:p></h2><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>There will be three ThinLTO bitcode blocks nested within an outer THINLTO_BLOCK, which itself is nested within the outer MODULE_BLOCK:</span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'><MODULE_BLOCK></span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'> ...</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'> <THINLTO_BLOCK BlockID=19 ...></span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'>   <THINLTO_SYMTAB_BLOCK BlockID=20 ...></span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'>   </THINLTO_SYMTAB_BLOCK></span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'>   <THINLTO_MODULE_STRTAB_BLOCK BlockID=21 ...></span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'>   </THINLTO_MODULE_STRTAB_BLOCK></span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'>   <THINLTO_FUNCTION_SUMMARY_BLOCK BlockID=22 ...></span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'>   </THINLTO_FUNCTION_SUMMARY_BLOCK></span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'> </THINLTO_BLOCK></span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'></MODULE_BLOCK></span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>These block IDs are defined along with other LLVM bitcode IDs in include/llvm/Bitcode/LLVMBitCodes.h:</span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'>namespace llvm {</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'>namespace bitc {</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'> // The only top-level block type defined is for a module.</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'> enum BlockIDs {</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'>   // Blocks</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'>   MODULE_BLOCK_ID          = FIRST_APPLICATION_BLOCKID,</span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'>   // Module sub-block id's</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'>   ...</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'>   THINLTO_BLOCK_ID,</span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'>   // ThinLTO sub-block id's.</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'>   THINLTO_SYMTAB_BLOCK_ID,</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'>   THINLTO_MODULE_STRTAB_BLOCK_ID</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'>   THINLTO_FUNCTION_SUMMARY_BLOCK_ID,</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New"'> };</span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>The outer THINLTO_BLOCK will contain a record with the version ID of the ThinLTO information, which will evolve as the importing algorithm is tuned.<span class=apple-converted-space> </span></span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>The exact record formats within each of the THINLTO_*_BLOCKs are still TBD, but the following is an overview of what they will contain:</span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><h4 style='margin-bottom:0in;margin-bottom:.0001pt'><u><span style='font-size:11.0pt;font-family:"Trebuchet MS","sans-serif";color:#666666;font-weight:normal'>THINLTO_SYMTAB_BLOCK</span></u><o:p></o:p></h4><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>This block contains a record for each function in the summary. The record will contain the ValueID of the corresponding function symbol in the VALUE_SYMTAB_BLOCK (which contains the function’s name string), as well as the bitcode offset of the corresponding function summary record. The latter enables fast seeking when the function summary section is read lazily.</span><o:p></o:p></p></div><h4 style='margin-bottom:0in;margin-bottom:.0001pt'><u><span style='font-size:11.0pt;font-family:"Trebuchet MS","sans-serif";color:#666666;font-weight:normal'>THINLTO_MODULE_STRTAB_BLOCK</span></u><o:p></o:p></h4><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>This block contains a record for each module with functions in the combined function index/summary file, holding the module ID and its path string (so that the module can be located during phase-3 importing). This block is not needed in the per-module function index/summary, as the module path is known by the linker when the file is loaded. Additionally, the unique module ID is assigned to each module by the phase-2 linker step when creating the combined index (used to attain consistent renaming during static promotion in the phase-3 backend).<span class=apple-converted-space> </span></span><o:p></o:p></p></div><h4 style='margin-bottom:0in;margin-bottom:.0001pt'><u><span style='font-size:11.0pt;font-family:"Trebuchet MS","sans-serif";color:#666666;font-weight:normal'>THINLTO_FUNCTION_SUMMARY_BLOCK</span></u><o:p></o:p></h4><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>This block contains a record for each function available for importing. At a minimum, it holds the index into the THINLTO_MODULE_STRTAB_BLOCK of the module containing the function, as well as the bitcode offset of the function’s FUNCTION_BLOCK within that module. The THINLTO_MODULE_STRTAB_BLOCK index will be 0 in the per-module function summary, as that section does not exist yet, but will be non-zero in the combined index/summary file (see Bitcode Combined Function Summary section below). It also will be used to hold information about the function that is useful in making importing decisions (e.g. its instruction count and profile entry count).</span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>There are several reasons for this block organization:</span><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-left:.5in;text-indent:-.25in;vertical-align:baseline'><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>1.</span><span style='font-size:7.0pt'>   <span class=apple-converted-space> </span></span><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>Nesting ThinLTO subblocks within an parent THINLTO_BLOCK allows the ThinLTO information to be quickly skipped during frontend parsing in the backend phase-3 parallel backend compile steps, when the ThinLTO information in the module is not needed.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-left:.5in;text-indent:-.25in;vertical-align:baseline'><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>2.</span><span style='font-size:7.0pt'>   <span class=apple-converted-space> </span></span><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>Nesting within the MODULE_BLOCK allows the THINLTO_SYMTAB_BLOCK records to share the function name strings with the MODULE_BLOCK’s function symbols. These strings are saved in the VALUE_SYMTAB_BLOCK nested within the Module block. Note that it would be faster to parse ThinLTO blocks during the phase-2 linker step if they were not nested within the MODULE_BLOCK (which could be skipped in one step using the size in the MODULE_BLOCK entry), since the phase-2 parser is only interested in the ThinLTO blocks. But this block placement enables greater size efficiency.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-left:.5in;text-indent:-.25in;vertical-align:baseline'><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>3.</span><span style='font-size:7.0pt'>   <span class=apple-converted-space> </span></span><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>Separating the ThinLTO function symtab information from the rest of the function summary has a couple of benefits:</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-left:1.0in;text-indent:-.25in;vertical-align:baseline'><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>a.</span><span style='font-size:7.0pt'>   <span class=apple-converted-space> </span></span><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>Mirrors how the information is structured in the native-wrapped case, where the native object symbol table is leveraged for holding the symbol name plus index into the summary section. This in turn enables better sharing of the bitcode parsing code and interfaces (discussed in more detail below in the native-wrapped description).</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-left:1.0in;text-indent:-.25in;vertical-align:baseline'><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>b.</span><span style='font-size:7.0pt'>   <span class=apple-converted-space> </span></span><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>Enables lazy reading of the function’s summary information, delayed until we are considering importing that function, while allowing fast checking of whether the function is available for importing (via presence in the ThinLTO function symtab).</span><o:p></o:p></p><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>Because, as mentioned earlier, the THINLTO_BLOCK and the rest of the MODULE_BLOCK are not typically both needed in a single compile step, we will implement a ThinLTO-specific bitcode reader class (ThinLTOBitcodeReader) to handle parsing of the ThinLTO blocks. This bitcode reader will hold a pointer to the ThinLTO data structure to be populated with the ThinLTO information (data structures described in a separate “ThinLTO File API and Data Structures” RFC which should be sent out at the same time). It will ignore all MODULE_BLOCK subblocks except the THINLTO_BLOCK, the BLOCKINFO_BLOCK containing abbrev IDs, and the VALUE_SYMTAB_BLOCK. The VALUE_SYMTAB_BLOCK parser is specialized/simplified since there will not be any Value objects created during ThinLTO parsing, we simply need to correlate each string with its ValueID in the VALUE_SYMTAB_BLOCK record.</span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><h2 style='margin-bottom:0in;margin-bottom:.0001pt'><span style='font-size:13.0pt;font-family:"Trebuchet MS","sans-serif"'>Bitcode Combined Function Summary</span><o:p></o:p></h2><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>The combined function index/summary (thin archive) file created by the phase-2 linker step will also be bitcode. It will consist of a MODULE_BLOCK containing only a THINLTO_BLOCK, a BLOCKINFO_BLOCK, and a VALUE_SYMTAB_BLOCK. The THINLTO_BLOCK will contain all three subblocks, with the THINLTO_SYMTAB_BLOCK and the THINLTO_FUNCTION_SUMMARY_BLOCK holding the aggregated per-module ThinLTO information. As noted earlier, it will also contain a THINLTO_MODULE_STRTAB_BLOCK created from the linked modules. The combined index will exclude symbols that are undefined, duplicate (e.g. comdats) or unlikely to benefit from importing. The THINLTO_FUNCTION_SUMMARY_BLOCK offsets in the THINLTO_SYMTAB_BLOCK records are updated to reflect the new offset into the combined THINLTO_FUNCTION_SUMMARY_BLOCK, and the THINLTO_FUNCTION_SUMMARY_BLOCK records are updated to include the appropriate module index into the THINLTO_MODULE_STRTAB_BLOCK.</span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><h1 style='margin-bottom:0in;margin-bottom:.0001pt'><span style='font-size:16.0pt;font-family:"Trebuchet MS","sans-serif";font-weight:normal'>Native-Wrapped ThinLTO Support</span><o:p></o:p></h1><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>This section describes the representation of ThinLTO for native-wrapped bitcode intermediate files. The discussion here uses ELF as an example, but should also apply to other formats such as COFF and Mach-O [1].</span><o:p></o:p></p></div><h2 style='margin-bottom:0in;margin-bottom:.0001pt'><span style='font-size:13.0pt;font-family:"Trebuchet MS","sans-serif"'>Native-wrapped bitcode</span><o:p></o:p></h2><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>There is already support in LLVM for reading native-wrapped bitcode, where the bitcode is contained within an .llvmbc section. For ThinLTO, unlike in the earlier bitcode-only case, the ThinLTO information is not nested within the MODULE_BLOCK contained within the .llvmbc section. Instead, the native object will contain a symbol table, and special sections holding the additional ThinLTO information. These sections are the function summary section (.llvm_thinlto_funcsum) containing the function’s bitcode offset and summary information for importing decisions, as well as the module path string table (.llvm_thinlto_modstrtab).</span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>For simplicity and consistency with the bitcode-only format and interfaces, the contents of the .llvm_thinlto_funcsum and .llvm_thinlto_modstrtab will be encoded with bitcode. The .llvm_thinlto_modstrtab section will contain bitcode for a single THINLTO_MODULE_STRTAB_BLOCK. The format and contents of this block will be identical to the equivalent block in the bitcode-only case. Similarly, the .llvm_thinlto_funcsum section will contain bitcode for a single THINLTO_FUNCTION_SUMMARY_BLOCK. The format and contents will be identical to the equivalent block in the bitcode-only case, however note that the bitcode offset for the FUNCTION_BLOCK is the offset within the .llvmbc section bitcode (which contains the function IR).</span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>As with the symbol table in a normal object file, the symbol table for the native-object wrapped bitcode file will hold entries for both defined and undefined but referenced symbols. The entries for functions defined in the module specify the location of that function’s summary via the st_shndx (index of .llvm_thinlto_funcsum section) and st_value (bitcode offset within .llvm_thinlto_funcsum section). The st_size field will hold the size of the function summary entry in the .llvm_thinlto_funcsum section. Note that for functions that are deemed unlikely to benefit from importing (e.g. large and cold), the summary data will be suppressed and the symtab entry will simply have a zero offset and size.</span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>The symbol’s visibility can be emitted in the st_other field which typically holds the visibility info. If a tool such as objcopy or ld -r modifies the symbol visibility, this change is recorded in the symbol table. The change will be propagated to the bitcode when the backend compiles the native-wrapped bitcode.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>E.g.:</span><o:p></o:p></p><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>Section Headers:</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'> [Nr] Name              Type             Address           Offset</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>      Size              EntSize          Flags  Link  Info  Align</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'> [ 0]                   NULL             0000000000000000  00000000</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>      0000000000000000  0000000000000000           0     0     0</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'> [ 1] .shstrtab         STRTAB           0000000000000000  0000024b</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>      0000000000000059  0000000000000000           0     0     1</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'> [ 2] .text             PROGBITS         0000000000000000  00000040</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>      0000000000000000  0000000000000000  AX       0     0     16</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>…</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'> [ 5] .llvmbc           PROGBITS         0000000000000000  00000040</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>      000000000000044c  0000000000000000   E       0     0     4</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'> [ 6] .llvm_thinlto_funcsum PROGBITS     0000000000000000  00000040</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>      0000000000000400  0000000000000000   E       0     0     4</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'> [ 7] .llvm_thinlto_modstrtab PROGBITS   0000000000000000  00000440<br>      0000000000000013  0000000000000000   E         0     0    4</span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>Symbol table '.symtab' contains 11 entries:</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>  Num:    Value          Size Type    Bind   Vis      Ndx Name</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>    0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND<span class=apple-converted-space> </span></span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>    1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS t1.c</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>    2: 0000000000000000     0 SECTION LOCAL  DEFAULT    2<span class=apple-converted-space> </span></span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>    3: 0000000000000000     0 SECTION LOCAL  DEFAULT    4<span class=apple-converted-space> </span></span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>    4: 0000000000000000     0 SECTION LOCAL  DEFAULT    5<span class=apple-converted-space> </span></span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>    5: 0000000000000000     0 SECTION LOCAL  DEFAULT    6<span class=apple-converted-space> </span></span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>    6: 0000000000000000     0 SECTION LOCAL  DEFAULT    7<span class=apple-converted-space> </span></span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>    7: 0000000000000000     0 SECTION LOCAL  DEFAULT    8<span class=apple-converted-space> </span></span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>    8: 0000000000000040    40 FUNC    GLOBAL DEFAULT    6 bar</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>    9: 0000000000000000    40 FUNC    GLOBAL DEFAULT    6 foo</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>   10: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND blah</span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>The section index value in the symtab entry for ‘foo’ are 6 and 0x0, respectively, meaning that the function summary info for ‘foo’ can be found in section 6 (.llvm_thinlto_funcsum) at offset 0x0. Similarly, the function summary info for ‘bar’ can be found in .llvm_thinlto_funcsum at offset 0x40. The size refers to the size of the corresponding function summary entry.</span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><h2 style='margin-bottom:0in;margin-bottom:.0001pt'><span style='font-size:13.0pt;font-family:"Trebuchet MS","sans-serif"'>Native-Wrapped Combined Function Summary</span><o:p></o:p></h2><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>The combined function summary (thin archive) file created by the phase-2 linker step can also be in native object format. It will contain the symbol table, and just the .llvm_thinlto_funcsum and .llvm_thinlto_modstrtab sections, combined across all of the linked modules. The combined symbol table, .llvm_thinlto_funcsum and .llvm_thinlto_modstrtab sections will exclude symbols that are undefined, duplicate (e.g. comdats) or unlikely to benefit from importing. The offsets in the symbol table are updated to reflect the new offset into the .llvm_thinlto_funcsum section, and the .llvm_thinlto_funcsum updated to include the appropriate module path index in the new .llvm_thinlto_modstrtab section.</span><o:p></o:p></p></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div></div><div><div><div><p class=MsoNormal>________________<o:p></o:p></p></div></div><div><div><p class=MsoNormal>[1] COFF and Mach-O symbol tables have similar fields. The main differences are that Mach-O symbol table entries don’t contain the symbol size, so the size is deduced by looking for the next symbol start address, and COFF holds the symbol sizes in auxiliary info that follows each symbol entry. See also<span class=apple-converted-space> </span><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.delorie.com_djgpp_doc_coff_symtab.html&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=oUy_PB_mSfRgDO7H7bZOR04gv_DMzX5rPO_lv4PHt60&s=7isNRRG84wFLU9ztTKYIXpp2tc_k91DwDH6bOpuOEsQ&e=" target="_blank"><span style='color:purple'>http://www.delorie.com/djgpp/doc/coff/symtab.html</span></a><span class=apple-converted-space> </span>and<span class=apple-converted-space> </span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.apple.com_library_mac_documentation_DeveloperTools_Conceptual_MachORuntime_index.html-23__apple-5Fref_c_tag_nlist-5F64&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=oUy_PB_mSfRgDO7H7bZOR04gv_DMzX5rPO_lv4PHt60&s=4XqKCNsoQF6E-9s1t50vPGyEPPRQOhjzbY8iGykl-vU&e=" target="_blank"><span style='color:purple'>https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachORuntime/index.html#//apple_ref/c/tag/nlist_64</span></a><o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><p class=MsoNormal>--<span class=apple-converted-space> </span><o:p></o:p></p></div><div><table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0><tr><td nowrap style='border:none;border-top:solid #D50F25 1.5pt;padding:0in 0in 0in 0in'><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#555555'>Teresa Johnson |</span><o:p></o:p></p></div></td><td nowrap style='border:none;border-top:solid #3369E8 1.5pt;padding:0in 0in 0in 0in'><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#555555'> Software Engineer |</span><o:p></o:p></p></div></td><td nowrap style='border:none;border-top:solid #009939 1.5pt;padding:0in 0in 0in 0in'><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#555555'> <a href="mailto:tejohnson@google.com" target="_blank"><span style='color:purple'>tejohnson@google.com</span></a> |</span><o:p></o:p></p></div></td><td nowrap style='border:none;border-top:solid #EEB211 1.5pt;padding:0in 0in 0in 0in'><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#555555'> <a href="tel:408-460-2413" target="_blank"><span style='color:purple'>408-460-2413</span></a></span><o:p></o:p></p></div></td></tr></table></div></div></div></div></blockquote></div></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p class=MsoNormal>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank"><span style='color:purple'>LLVMdev@cs.uiuc.edu</span></a><span class=apple-converted-space> </span>        <a href="http://llvm.cs.uiuc.edu/" target="_blank"><span style='color:purple'>http://llvm.cs.uiuc.edu</span></a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank"><span style='color:purple'>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</span></a><o:p></o:p></p></div></div></blockquote></div></div><div><p class=MsoNormal><br><br clear=all><o:p></o:p></p></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><p class=MsoNormal>--<span class=apple-converted-space> </span><o:p></o:p></p></div><div><table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0><tr><td nowrap style='border:none;border-top:solid #D50F25 1.5pt;padding:0in 0in 0in 0in'><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#555555'>Teresa Johnson |</span><o:p></o:p></p></div></td><td nowrap style='border:none;border-top:solid #3369E8 1.5pt;padding:0in 0in 0in 0in'><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#555555'> Software Engineer |</span><o:p></o:p></p></div></td><td nowrap style='border:none;border-top:solid #009939 1.5pt;padding:0in 0in 0in 0in'><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#555555'> <a href="mailto:tejohnson@google.com" target="_blank"><span style='color:purple'>tejohnson@google.com</span></a> |</span><o:p></o:p></p></div></td><td nowrap style='border:none;border-top:solid #EEB211 1.5pt;padding:0in 0in 0in 0in'><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#555555'> 408-460-2413</span><o:p></o:p></p></div></td></tr></table></div></div></div></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></div></div></div></body></html>