<div dir="ltr">Hi David,<div>Thanks for the comments, replies below.</div><div>Teresa<br><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 30, 2018 at 11:52 AM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Teresa,<br><br>Awesome to see - looking forward to it!<br><br><div class="gmail_quote"></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Apr 24, 2018 at 7:44 AM Teresa Johnson 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi everyone,<div><br></div><div>I started working on a long-standing request to have the summary dumped in a readable format to text, and specifically to emit to LLVM assembly. Proposal below, please let me know your thoughts.</div><div><br></div><div>Thanks,</div><div>Teresa</div><div><br></div><div><b style="font-weight:normal" id="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-docs-internal-guid-737316de-f81b-6dbe-8709-b6a8255a9c91"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">RFC: LLVM Assembly format for ThinLTO Summary</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">========================================</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Background</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">-----------------</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">ThinLTO operates on small summaries computed during the compile step (i.e. with “-c -flto=thin”), which are then analyzed and updated during the Thin Link stage, and utilized to perform IR updates during the post-link ThinLTO backends. The summaries are emitted as LLVM Bitcode, however, not currently in the LLVM assembly.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">There are two ways to generate a bitcode file containing summary records for a module:</span></p><ol style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:decimal;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Compile with “clang -c -flto=thin”</span></p></li></ol></b></div></div></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><div><br>As an aside - I seem to recall that at least internally at Google some kind of summary-only bitcode files are used (so that the whole bitcode file (especially in builds with debug info) doesn't have to be shipped to the node doing the summary merging). How are those summary-only files produced? Is that upstream? Or done in a more low-level way (like an objcopy, llvm-* tool invocation done as a post-processing step, etc)?</div></div></div></div></blockquote><div><br></div><div>This is done upstream, under a special clang option that can be given in addition to -flto=thin, so that the compile step emits both the full IR+summary (for the distributed backends) as well as a minimized bitcode file with summary (for the thin link). Note that the distributed backends don't actually need the summary with the IR (as it gets all the info it needs from the combined summary index written out by the thin link), so we could theoretically improve this to suppress the summary write for that first file under that option.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><b style="font-weight:normal" id="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-docs-internal-guid-737316de-f81b-6dbe-8709-b6a8255a9c91"><ol style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:decimal;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Build from LLVM assembly using “opt -module-summary”</span></p></li></ol><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Either of these will result in the ModuleSummaryIndex analysis pass (which builds the summary index in memory for a module) to be added to the pipeline just before bitcode emission.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Additionally, a combined index is created by merging all the per-module indexes during the Thin Link, which is optionally emitted as a bitcode file.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Currently, the only way to view these records is via “llvm-bcanalyzer -dump”, then manually decoding the raw bitcode dumps.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Relatedly, there is YAML reader/writer support for CFI related summary fields (-wholeprogramdevirt-read-summary and -wholeprogramdevirt-write-summary). Last summer, GSOC student Charles Saternos implemented support to dump the summary in YAML from llvm-lto2 (D34080), including the rest of the summary fields (D34063), however, there was pushback on the related RFC for dumping via YAML or another format rather than emitting as LLVM assembly.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Goals:</span></p><br><ol style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:decimal;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Define LLVM assembly format for summary index</span></p></li><li dir="ltr" style="list-style-type:decimal;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Define interaction between parsing of summary from LLVM assembly and synthesis of new summary index from IR.</span></p></li><li dir="ltr" style="list-style-type:decimal;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Implement printing and parsing of summary index LLVM assembly</span></p></li></ol><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Proposed LLVM Assembly Format</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">----------------------------------------------</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">There are several top level data structures within the ModuleSummaryIndex:</span></p><ol style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:decimal;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">ModulePathStringTable: Holds the paths to the modules summarized in the index (only one entry for per-module indexes and multiple in the combined index), along with their hashes (for incremental builds and global promotion).</span></p></li><li dir="ltr" style="list-style-type:decimal;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">GlobalValueMap: A map from global value GUIDs to the corresponding function/variable/alias summary (or summaries for the combined index and weak linkage).</span></p></li><li dir="ltr" style="list-style-type:decimal;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">CFI-related data structures (TypeIdMap, CfiFunctionDefs, and CfiFunctionDecls)</span></p></li></ol><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">I have a WIP patch to AsmWriter.cpp to print the ModuleSummaryIndex that I was using to play with the format. It currently prints 1 and 2 above. I’ve left the CFI related summary data structures as a TODO for now, until the format is at least conceptually agreed, but from looking at those I don’t see an issue with using the same format (with a note/question for Peter on CFI type test representation below).</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">I modeled the proposed format on metadata, with a few key differences noted below. Like metadata, I propose enumerating the entries with the SlotTracker, and prefixing them with a special character. Avoiding characters already used in some fashion (i.e. “!” for metadata and “#” for attributes), I initially have chosen “^”. Open to suggestions though.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Consider the following example:</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">extern void foo();</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br class="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-kix-line-break"></span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">int X;</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br class="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-kix-line-break"></span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">int bar() {</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br class="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-kix-line-break"></span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">  foo();</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br class="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-kix-line-break"></span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">  return X;</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br class="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-kix-line-break"></span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">}</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br class="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-kix-line-break"></span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">void barAlias() __attribute__ ((alias ("bar")));</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br class="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-kix-line-break"></span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">int main() {</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br class="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-kix-line-break"></span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">  barAlias();</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br class="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-kix-line-break"></span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">  return bar();</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br class="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-kix-line-break"></span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">}</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br class="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-kix-line-break"><br class="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-kix-line-break"></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">The proposed format has one entry per ModulePathStringTable entry and one per GlobalValueMap/GUID, and looks like:</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">^0 = module: {path: testA.o, hash: 5487197307045666224}</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br class="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-kix-line-break"></span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">^1 = gv: {guid: 1881667236089500162, name: X, summaries: {variable: {module: ^0, flags: {linkage: common, notEligibleToImport: 0, live: 0, dsoLocal: 1}}}}</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br class="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-kix-line-break"></span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">^2 = gv: {guid: 6699318081062747564, name: foo}</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br class="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-kix-line-break"></span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">^3 = gv: {guid: 15822663052811949562, name: main, summaries: {function: {module: ^0, flags: {linkage: extern, notEligibleToImport: 1, live: 0, dsoLocal: 1}, insts: 5, funcFlags: {readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0}, calls: {{callee: ^5, hotness: unknown}, {callee: ^4, hotness: unknown}}}}}</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br class="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-kix-line-break"></span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">^4 = gv: {guid: 16434608426314478903, name: bar, summaries: {function: {module: ^0, flags: {linkage: extern, notEligibleToImport: 1, live: 0, dsoLocal: 1}, insts: 3, funcFlags: {readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0}, calls: {{callee: ^2, hotness: unknown}}, refs: {^1}}}}</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br class="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-kix-line-break"></span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">^5 = gv: {guid: 18040127437030252312, name: barAlias, summaries: {alias: {module: ^0, flags: {linkage: extern, notEligibleToImport: 0, live: 0, dsoLocal: 1}, aliasee: ^4}}}</span></p></b></div></div></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><div><br>Syntax seems pretty good to me!</div></div></div></div></blockquote><div><br></div><div>Great!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><b style="font-weight:normal" id="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-docs-internal-guid-737316de-f81b-6dbe-8709-b6a8255a9c91"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Like metadata, the fields are tagged (currently using lower camel case, maybe upper camel case would be preferable).</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">The proposed format has a structure that reflects the data structures in the summary index. For example, consider the entry “^4”. This corresponds to the function “bar”. The entry for that GUID in the GlobalValueMap contains a list of summaries. For per-module summaries such as this, there will be at most one summary (with no summary list for an external function like “foo”). In the combined summary there may be multiple, e.g. in the case of linkonce_odr functions which have definitions in multiple modules. The summary list for bar (“^4”) contains a FunctionSummary, so the summary is tagged “function:”. The FunctionSummary contains both a flags structure (inherited from the base GlobalValueSummary class), and a funcFlags structure (specific to FunctionSummary). It therefore contains a brace-enclosed list of flag tags/values for each.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Where a global value summary references another global value summary (e.g. via a call list, reference list, or aliasee), the entry is referenced by its slot. E.g. the alias “barAlias” (“^5”) references its aliasee “bar” as “^4”.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Note that in comparison metadata assembly entries tend to be much more decomposed since many metadata fields are themselves metadata (so then entries tend to be shorter with references to other metadata nodes).</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br class="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-kix-line-break"><br class="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-kix-line-break"></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Currently, I am emitting the summary entries at the end, after the metadata nodes. Note that the ModuleSummaryIndex is not currently referenced from the Module, and isn’t currently created when parsing the Module IR bitcode (there is a separate derived class for reading the ModuleSummaryIndex from bitcode). This is because they are not currently used at the same time. However, in the future there is no reason why we couldn’t tag the global values in the Module’s LLVM assembly with the corresponding summary entry if the ModuleSummaryIndex is available when printing the Module in the assembly writer. I.e. we could do the following for “main” from the above example when printing the IR definition (note the “^3” at the end):</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">define  dso_local i32 @main() #0 !dbg !17 ^3 {</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">For CFI data structures, the format would be similar. It appears that TypeIds are referred to by string name in the top level TypeIdMap (std::map indexed by std::string type identifier), whereas they are referenced by GUID within the FunctionSummary class (i.e. the TypeTests vector and the VFuncId structure). For the LLVM assembly I think there should be a top level entry for each TypeIdMap, which lists both the type identifier string and its GUID (followed by its associated information stored in the map), and the TypeTests/VFuncId references on the FunctionSummary entries can reference it by summary slot number. I.e. something like:</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">^1 = typeid: {guid: 12345, identifier: name_of_type, …</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">^2 = gv: {... {function: {.... typeTests: {^1, …</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Peter - is that correct and does that sound ok?</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Issues when Parsing of Summaries from Assembly</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">--------------------------------------------------------------------</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">When reading an LLVM assembly file containing module summary entries, a ModuleSummaryIndex will be created from the entries.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Things to consider are the behavior when:</span></p><ul style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:disc;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Invoked with “opt -module-summary” (which currently builds a new summary index from the IR). </span><span style="background-color:transparent;font-size:11pt">Options:</span></p></li></ul></b></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><b style="font-weight:normal" id="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-docs-internal-guid-737316de-f81b-6dbe-8709-b6a8255a9c91"><ul style="margin-top:0pt;margin-bottom:0pt"><ol style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:lower-alpha;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">recompute summary and throw away summary in the assembly file</span></p></li></ol></ul></b></div></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><div><br>What happens currently if you run `opt -module-summary` on a bitcode file that already contains a summary? I feel like the behavior should be the same when run on a textual IR file containing a summary, probably?<br></div></div></div></div></blockquote><div><br></div><div>We rebuild the summary. Note that this in part is due to the fact mentioned above that we have separate readers for the Module IR and the summary. The opt tool does not even read the summary if present. We currently only read the summary during the thin link (when building the combined index for analysis), and in the distributed backends where we read the combined summary index file emitted for that file by the distributed thin link.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> </div></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><b style="font-weight:normal" id="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-docs-internal-guid-737316de-f81b-6dbe-8709-b6a8255a9c91"><ul style="margin-top:0pt;margin-bottom:0pt"><ol style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:lower-alpha;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">ignore -module-summary and build the summary from the LLVM assembly</span></p></li><li dir="ltr" style="list-style-type:lower-alpha;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">give an error</span></p></li><li dir="ltr" style="list-style-type:lower-alpha;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">compare the two summaries (one created from the assembly and the new one created by the analysis phase from the IR), and error if they are different.</span></p></li></ol></ul><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-left:36pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">My opinion is to do a),  so that the behavior using -module-summary doesn’t change. We also need a way to force building of a fresh module summary for cases where the user has modified the LLVM assembly of the IR (see below).</span></p><br><ul style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:disc;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">How to handle older LLVM assembly files that don’t contain new summary fields. Options:</span></p></li></ul></b></div></div></blockquote><div><br>Same thoughts would apply here for "what do we do in the bitcode case" - with the option to not support old/difficult textual IR. If there are easy/obvious defaults, I'd say it's probably worth baking those in (& baking them in even for the existing fields we know about, to make it easier to write more terse test cases that don't have to verbosily/redundantly specify lots of default values?) to the parsing/loading logic?<br></div></div></div></div></blockquote><div><br></div><div>So we do emit an index version in the bitcode, and auto-upgrade in a conservative manner anything that wasn't emitted prior. We could presumably serialize out the version number and handle auto-upgrading from textual assembly the same way (as the version is bumped beyond the current version at least). If we want to allow omission of some fields for test simplicity, we could do a similar thing and apply conservative values where possible for omitted fields (e.g. the flags). That seems fine to me, in which case I don't think we need a version number. Although this has implications for the validator, see below.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><b style="font-weight:normal" id="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail-docs-internal-guid-737316de-f81b-6dbe-8709-b6a8255a9c91"><ul style="margin-top:0pt;margin-bottom:0pt"><ol style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:lower-alpha;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Force the LLVM assembly file to be recreated with a new summary. I.e. “opt -module-summary -o - | llvm-dis”.</span></p></li><li dir="ltr" style="list-style-type:lower-alpha;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Auto-upgrade, by silently creating conservative values for the new summary entries.</span></p></li></ol></ul><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-left:36pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">I lean towards b) (when possible) for user-friendliness and to reduce required churn on test inputs.</span></p><br><ul style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:disc;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">How to handle partial or incorrect LLVM assembly summary entries. How to handle partial summaries depends in part on how we answer the prior question about auto-upgrading. I think the best option like there is to handle it automatically when possible. However, I do think we should error on glaring errors like obviously missing information. For example, when there is summary data in the LLVM assembly, but summary entries are missing for some global values. E.g. if the user modified the assembly to add a function but forgot to add a corresponding summary entry. We could still have subtle issues (e.g. user adds a new call but forgets to update the caller’s summary call list), but it will be harder to detect those.</span></p></li></ul></b></div></div></blockquote><div><br>I'd be OK with the summary being validated by the IR validator (same way other properties of IR are validated & even simple things like if you use the wrong IR type to refer to an IR value, you get a parse error, etc) - which, I realize, would make it feel like the textual summary was entirely redundant</div></div></div></div></blockquote><div><br></div><div>It is redundant when the IR is also available, which relates to Peter and others' objections to serializing this back in. An issue with validation would be if we allowed omission of some fields and/or auto-upgrading as discussed above. The applied conservative values might very well not match the recomputed values. But as I mentioned here we may just want to validate for glaring errors like required info - i.e. I think we should require that every GV has an associated summary entry.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> (except in cases of standalone summaries - which I imagine will be the common case in tests, because the summary processing should be tested in isolation (except for testing things like this validation logic itself, etc)).<br></div></div></div></div></blockquote><div><br></div><div>Yes, I suspect the biggest usage in tests would be a standalone combined summary file that we can use to test the application of the thin link optimizations on a single IR file in the LTO backend pipeline. I.e the input to the test would be one module IR assembly file (no summary) and one combined index assembly file, it would run just the ThinLTO backend pipeline, and check the resulting IR via llvm-dis to ensure the optimization is applied effectively.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><div><br></div>-- <br><div dir="ltr" class="m_-8247471043930259967m_-6282592664665362543m_7176755675071458496m_5566797023899818392m_-8889427497467293304gmail_signature"><span style="font-family:Times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td style="border-top:2px solid rgb(213,15,37)">Teresa Johnson |</td><td style="border-top:2px solid rgb(51,105,232)"> Software Engineer |</td><td style="border-top:2px solid rgb(0,153,57)"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td style="border-top:2px solid rgb(238,178,17)"> <a href="tel:(408)%20460-2413" value="+14084602413" target="_blank">408-460-2413</a></td></tr></tbody></table></span></div></div></div>
_______________________________________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_-8247471043930259967m_-6282592664665362543gmail_signature" data-smartmail="gmail_signature"><span style="font-family:Times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Teresa Johnson |</td><td style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"> 408-460-2413</td></tr></tbody></table></span></div></div></div>