<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 17, 2017 at 6:11 AM Charles Saternos via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">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"><div><span style="font-size:12.8px">Hey @chandlerc and @dblaikie,</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Any updates on this in relation to "</span>[PATCH] D34080: [ThinLTO] Add dump-summary command to llvm-lto2 tool"?</div></div></blockquote><div><br>Sorry you've kind of got stuck in the middle of this - but I'm still hoping to hear/understand the pushback on implementing this as a first class .ll construct with serialization and deserialization support.<br><br>I think Peter mentioned he didn't think this was the right path forward in the long term? If that's the case, I'd like to understand that/reach that conclusion for the project now rather than treating this as a stop-gap with some idea that in the future someone might implement full serialization support (when it's been over a year already, and other stop gaps have been implemented (the yaml input support) already).<br><br>& if a .ll construct with serialization/deserialization is the path forward, understanding the motivation for a something other than going straight for that would be helpful - usually bitcode features come with .ll support from day 1, not a year later. I'm not clear on what would make this feature an exception/more expensive to do this for (& why it would be worth deferring that work, and what/when that work will be motivated/done)<br><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>Thanks,</div><div>Charles</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 9, 2017 at 3:58 PM, Charles Saternos <span dir="ltr"><<a href="mailto:charles.saternos@gmail.com" target="_blank">charles.saternos@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>OK, I tested the hotness, and it works.</div><span><div><br></div>> <span style="font-size:12.8px">I'd ask Charles to take it over. I think it just needs a test case and an update to the usage message.</span><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">Sure - I've added the message and a quick test. The patch is here: <a href="https://reviews.llvm.org/D34063" target="_blank">https://reviews.llvm.org/D34063</a></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Thanks,</span></div><div><span style="font-size:12.8px">Charles</span></div></div><div class="m_3022482615460374060HOEnZb"><div class="m_3022482615460374060h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 8, 2017 at 8:01 PM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'd ask Charles to take it over. I think it just needs a test case and an update to the usage message.<div><div><div><br></div><div>Peter</div></div></div></div><div class="gmail_extra"><div><div class="m_3022482615460374060m_8239462255096530888h5"><br><div class="gmail_quote">On Thu, Jun 8, 2017 at 4:55 PM, Teresa Johnson via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Great! For the hotness, try creating a small test case with a very hot loop that iterates many times. Let me know if you are still having trouble. While the llvm-dis serialization is being discussed, I suppose at the very least this can go in with the rest of the existing YAML summary dumping and get emitted from llvm-lto2 using the patch Peter attached. Peter - do you want to add that to llvm-lto2 so that we have a way of dumping the existing YAML supported summary info to stdout, or would you rather have Charles take that one over and submit it (probably just needs a test case).<div><br></div><div>Teresa</div></div><div class="m_3022482615460374060m_8239462255096530888m_-6056255571509950643HOEnZb"><div class="m_3022482615460374060m_8239462255096530888m_-6056255571509950643h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 8, 2017 at 4:16 PM, Charles Saternos <span dir="ltr"><<a href="mailto:charles.saternos@gmail.com" target="_blank">charles.saternos@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey Teresa,<div><br></div><div>I've updated the YAML to include the names and GUIDs for all functions/global vars/aliases. I've also added the hotness info to the output, but for some reason, none of my tests when running with FDO gave anything besides Unknown. I'll be looking more into this tomorrow.</div><div><br></div><div>Here's the current format:</div><div><br></div><div><div>> ../build/bin/llvm-lto2 dump-summary b.o</div><div>---</div><div>NamedGlobalValueMap:</div><div> :</div><div> - GUID: 3762489268811518743</div><div> Kind: GlobalVar</div><div> Linkage: PrivateLinkage</div><div> NotEligibleToImport: true</div><div> Live: false</div><div> cold:</div><div> - GUID: 11668175513417606517</div><div> Kind: Function</div><div> Linkage: ExternalLinkage</div><div> NotEligibleToImport: true</div><div> Live: false</div><div> InstCount: 5</div><div> Calls:</div><div> - Name: puts</div><div> GUID: 8979701042202144121</div><div> Hotness: Unknown</div><div> fib:</div><div> - GUID: 8667248078361406812</div><div> Kind: Function</div><div> Linkage: ExternalLinkage</div><div> NotEligibleToImport: true</div><div> Live: false</div><div> InstCount: 26</div><div> Calls:</div><div> - Name: fib</div><div> GUID: 8667248078361406812</div><div> Hotness: Unknown</div><div> hot:</div><div> - GUID: 10177652421713147431</div><div> Kind: Function</div><div> Linkage: ExternalLinkage</div><div> NotEligibleToImport: true</div><div> Live: false</div><div> InstCount: 14</div><div> Calls:</div><div> - Name: fib</div><div> GUID: 8667248078361406812</div><div> Hotness: Unknown</div><div> - Name: printf</div><div> GUID: 7383291119112528047</div><div> Hotness: Unknown</div><div> llvm.used:</div><div> - GUID: 15665353970260777610</div><div> Kind: GlobalVar</div><div> Linkage: AppendingLinkage</div><div> NotEligibleToImport: true</div><div> Live: true</div><div>TypeIdMap:</div><div>WithGlobalValueDeadStripping: false</div><div>...</div></div><div><br></div><div>Thanks,</div><div>Charles</div><div><br></div></div><div class="m_3022482615460374060m_8239462255096530888m_-6056255571509950643m_136260568403745153HOEnZb"><div class="m_3022482615460374060m_8239462255096530888m_-6056255571509950643m_136260568403745153h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 7, 2017 at 12:38 PM, Teresa Johnson <span dir="ltr"><<a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_3022482615460374060m_8239462255096530888m_-6056255571509950643m_136260568403745153m_-5144985227535058042h5">On Wed, Jun 7, 2017 at 8:58 AM, Charles Saternos <span dir="ltr"><<a href="mailto:charles.saternos@gmail.com" target="_blank">charles.saternos@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Alright, now it outputs YAML in the following format:<div><br></div><div><div>---</div><div>NamedGlobalValueMap:</div><div> X:</div><div> - Kind: GlobalVar</div><div> Linkage: ExternalLinkage</div><div> NotEligibleToImport: false</div><div> Live: false</div><div> a:</div><div> - Kind: Alias</div><div> Linkage: WeakAnyLinkage</div><div> NotEligibleToImport: false</div><div> Live: false</div><div> AliaseeGUID: 1881667236089500162</div><div> afun:</div><div> - Kind: Function</div><div> Linkage: ExternalLinkage</div><div> NotEligibleToImport: false</div><div> Live: false</div><div> InstCount: 2</div><div> testtest:</div><div> - Kind: Function</div><div> Linkage: ExternalLinkage</div><div> NotEligibleToImport: false</div><div> Live: false</div><div> InstCount: 2</div><div> Calls:</div><div> - Function: 14471680721094503013</div><div>TypeIdMap:</div><div>WithGlobalValueDeadStripping: false</div><div>...</div></div><div><br></div><div>Any thoughts on the new format?</div></div></blockquote><div><br></div></div></div><div>Thanks, Charles. The main improvement I think we would want is to output value names instead of the GUID. Can you build up a map from GUID -> name ahead of time and use those like you were for your initial patch? Actually, I also think it would be useful to emit both the GUID and the name, since the combined index will eventually only have the GUID, so this would give a mapping to use for at least the visual inspection of the combined index.</div><div><br></div><div>Also, would be good to see an example with FDO, to make sure the hotness info of the calls is emitted.</div><span class="m_3022482615460374060m_8239462255096530888m_-6056255571509950643m_136260568403745153m_-5144985227535058042HOEnZb"><font color="#888888"><div><br></div><div>Teresa</div></font></span><div><div class="m_3022482615460374060m_8239462255096530888m_-6056255571509950643m_136260568403745153m_-5144985227535058042h5"><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><br></div><div>Thanks,</div><div>Charles</div></div><div class="m_3022482615460374060m_8239462255096530888m_-6056255571509950643m_136260568403745153m_-5144985227535058042m_8142105524887194629HOEnZb"><div class="m_3022482615460374060m_8239462255096530888m_-6056255571509950643m_136260568403745153m_-5144985227535058042m_8142105524887194629h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 6, 2017 at 5:21 PM, Mehdi AMINI <span dir="ltr"><<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>2017-06-06 13:38 GMT-07:00 David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span class="m_3022482615460374060m_8239462255096530888m_-6056255571509950643m_136260568403745153m_-5144985227535058042m_8142105524887194629m_-2996137490119287995m_6069972045809477405gmail-"><div dir="ltr">On Tue, Jun 6, 2017 at 1:26 PM Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-06-05 14:27 GMT-07:00 David Blaikie via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">I know there's been a bunch of discussion here already, but I was wondering if perhaps someone (probably Teresa? Peter?) could:<br><br>1) summarize the current state<br>2) describe the end-goal<br>3) describe what steps (& how this patch relates) are planned to get to (2)<br><br>My naive thoughts, not being intimately familiar with any of this: Usually bitcode and textual IR support go in together or around the same time, and designed that way from the start (take r211920 for examaple, which added an explicit representation of COMDATs to the IR). This seems to have been an oversight in the implementation of IR summaries (is that an accurate representation/statement?)</div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>More or less: it was not an oversight. </div><div>The summaries are not really part of the IR, it is more like an "analysis result" that is serialized. It can always be recomputed from the IR. This aspect makes it quite "special", it is the only analysis result that I know of that we serialize.</div></div></div></div></blockquote></span><div><br>The use list work seems pretty similar in some ways (granted, can't be recomputed to match, hence the desire to serialize it for test case implementation).<br></div></div></div></blockquote><div><br></div></span><div>I see use-list as a leaky implementation detail of the IR that we serialized because it impact the processing of the IR.</div><div><br></div><div>Summaries are more like serializing the CFG for example.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>But it looks like the same is true here to a degree - there are test cases that exercise the summary handling, so they want summaries for input (for now, I think, I've seen test cases that run another LLVM tool to insert/create a summary to then feed that back in for a test), or to test that the resulting summary is correct.<br></div></div></div></blockquote><div><br></div></span><div>We have cases were we want summaries as an input and check a combined summary as an output, and for these having the YAML representation will be useful (we didn't have it before).</div><span><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br>Can summaries be standalone? I thought they could (that'd be ideal for the distributed situation - only the summary needs to go to the 'thin link' step, I think? (currently maybe only the debug info is stripped for that - but ideally other unused IR wouldn't be shipped there as well, I would think)<br></div></div></div></blockquote><div><br></div></span><div>Yes conceptually they can be standalone.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><span class="m_3022482615460374060m_8239462255096530888m_-6056255571509950643m_136260568403745153m_-5144985227535058042m_8142105524887194629m_-2996137490119287995m_6069972045809477405gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"> & now there's an effort to correct that. </div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The main motivation here, I believe, is more to help dev to have human readable/understandable dump for ThinLTO bitcodes. Having to inspect separately summaries is a pain.</div></div></div></div></blockquote></span><div><br>Not sure I quite follow - inspect separately? </div></div></div></blockquote><div><br></div></span><div>llvm-dis does not display summaries today, so you can't just use llvm-dis like a "regular" flow.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>How are they inspected today?<br></div></div></div></blockquote><div><br></div></span><div>llvm-bcanalyzer? And now the YAML dump as well.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>& also, I think there are test cases that want to/are currently testing summary input but do so somewhat awkwardly by using another tool to produce the summary first. Ideally the test case would have the summary written in to start, I would think, if that's a codepath worth testing?<br></div></div></div></blockquote><div><br></div></span><div>The IR already contains all the information, so why repeating it? This makes the test case harder to maintain, in the vast majority, I expect that if a test needs IR then it shouldn't need to include a summary as well (and vice-versa).</div><div><br></div><div>In the majority of test we have we want to check if the importing does what it is supposed to do, and if the linkage are correctly adjusted. With a YAML (or other) serialization for the summaries this could indeed been done purely with summaries, without any IR involved.</div><span class="m_3022482615460374060m_8239462255096530888m_-6056255571509950643m_136260568403745153m_-5144985227535058042m_8142105524887194629m_-2996137490119287995HOEnZb"><font color="#888888"><div><br></div><div>-- </div><div>Mehdi</div></font></span><div><div class="m_3022482615460374060m_8239462255096530888m_-6056255571509950643m_136260568403745153m_-5144985227535058042m_8142105524887194629m_-2996137490119287995h5"><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br>- Dave<br> </div><div><div class="m_3022482615460374060m_8239462255096530888m_-6056255571509950643m_136260568403745153m_-5144985227535058042m_8142105524887194629m_-2996137490119287995m_6069972045809477405gmail-h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><div> -- </div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Mehdi</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">So it seems like that would start with a discussion of what the right end-state would be: What the syntax in textual IR should be, then implementing it. I can understand implementing such a thing in steps - it's perhaps more involved than the COMDAT situation. In that case starting on either side seems fine - implementing the emission first (hidden behind a flag, so as not to break round-tripping in the interim) or the parsing first (no need to hide it behind any flags - manually written examples can be used as input tests).<br><br>(& it sounds like there's some partially implemented functionality using a YAML format that was intended to address how some test cases could be written? & this might be a good basis for the syntax - but seems to me like it might be a bit disjointed/out of place in the textual IR format that's not otherwise YAML-based?)<br><br>- Dave<br><br><div class="gmail_quote"><div><div class="m_3022482615460374060m_8239462255096530888m_-6056255571509950643m_136260568403745153m_-5144985227535058042m_8142105524887194629m_-2996137490119287995m_6069972045809477405gmail-m_-6875764543502098033m_-4013738782446964300h5"><div dir="ltr">On Fri, Jun 2, 2017 at 8:46 AM Charles Saternos via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div class="m_3022482615460374060m_8239462255096530888m_-6056255571509950643m_136260568403745153m_-5144985227535058042m_8142105524887194629m_-2996137490119287995m_6069972045809477405gmail-m_-6875764543502098033m_-4013738782446964300h5"><div dir="ltr">Hey all,<div><br></div><div>Below is the proposed format for the dump of the ThinLTO module summary in the llvm-dis utility:</div><div><br></div><div>> ../build/bin/llvm-dis t.o && cat t.o.ll</div><div><div>; ModuleID = '2.o'</div><div>source_filename = "2.ll"</div><div>target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"</div><div>target triple = "x86_64-unknown-linux-gnu"</div><div><br></div><div>@X = constant i32 42, section "foo", align 4</div><div><br></div><div>@a = weak alias i32, i32* @X</div><div><br></div><div>define void @afun() {</div><div> %1 = load i32, i32* @a</div><div> ret void</div><div>}</div><div><br></div><div>define void @testtest() {</div><div> tail call void @boop()</div><div> ret void</div><div>}</div><div><br></div><div>declare void @boop()</div><div><br></div><div>; Module summary:</div><div>; testtest (External linkage)</div><div>; Function (2 instructions)</div><div>; Calls: boop</div><div>; X (External linkage)</div><div>; Global Variable</div><div>; afun (External linkage)</div><div>; Function (2 instructions)</div><div>; Refs:</div><div>; a</div><div>; a (Weak any linkage)</div><div>; Alias (aliasee X)</div></div><div><br></div><div>I've implemented the above format in the llvm-dis utility, since there currently isn't really a way of getting ThinLTO summaries in a human-readable format.</div><div><br></div><div>Let me know what you think of this format, and what information you think should be added/removed.</div><div><br></div><div>Thanks,</div><div>Charles</div><div><br></div></div></div></div><span>
_______________________________________________<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>
</span></blockquote></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="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>
<br></blockquote></div></div></div></blockquote></div></div></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br><br clear="all"><span><div><br></div>-- <br><div class="m_3022482615460374060m_8239462255096530888m_-6056255571509950643m_136260568403745153m_-5144985227535058042m_8142105524887194629gmail_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 nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Teresa Johnson |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap 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 nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"> <a href="tel:(408)%20460-2413" value="+14084602413" target="_blank">408-460-2413</a></td></tr></tbody></table></span></div>
</span></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_3022482615460374060m_8239462255096530888m_-6056255571509950643m_136260568403745153gmail_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 nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Teresa Johnson |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap 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 nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"> <a href="tel:(408)%20460-2413" value="+14084602413" target="_blank">408-460-2413</a></td></tr></tbody></table></span></div>
</div>
</div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br></div></div><span class="m_3022482615460374060m_8239462255096530888HOEnZb"><font color="#888888"><div class="m_3022482615460374060m_8239462255096530888m_-6056255571509950643gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></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>