<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 5, 2017 at 4:21 PM Teresa Johnson <<a href="mailto:tejohnson@google.com">tejohnson@google.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"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 5, 2017 at 2:27 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@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">I know there's been a bunch of discussion here already, but I was wondering if perhaps someone (probably Teresa? Peter?) could:<br></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Sure</div></div></div></div></blockquote><div><br>Thanks!<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><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">1) summarize the current state<br></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Currently the summary is not dumped in the llvm-dis output. The only way to see it (other than some YAML dumping Peter added for the type test summary info), is to use llvm-bcanalyzer -dump, which is not easily readable.</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">2) describe the end-goal<br></div></blockquote><div><br></div><div>At the very least, dumping it in human readable form, ideally in the llvm-dis output (although dumping it separately may be useful as well), so that one can do verification/visual inspection, and also help get an understanding of why importing and other whole program optimizations are (not) being applied. </div><div><br></div><div>A further possible end goal is to be able to then construct the summary from this textual form, rather than reconstructing from the IR. This can be useful for testing purposes (as in the type test summary case Peter added), i.e. test what happens if I adjust the summary info.</div></div></div></div></blockquote><div><br></div><div>So I'd like to be a bit more clear here that I think this (roundtrippable) really should be the end goal, but it's certainly not my wheelhouse so I might be barking up the wrong tree, for sure.<br><br>It's my recollection that there are test cases for ThinLTO that need to run compile steps to generate inputs with summaries to exercise the code they need to test - is that correct? That seems to be a symptom of this information being missing (perhaps optionally) from the textual IR input.<br><br>Ah, I've got a better example: r216025 (Duncan's implementation of use-list order preservation in the IR).</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 class="gmail_extra"><div class="gmail_quote"><div> But other questions need to be worked through first - i.e. what happens if the user hand changes the textual IR but not the textual summary - how do we detect that the summary needs to be rebuilt vs read in and used as is...</div></div></div></div></blockquote><div><br>For textual IR when the IR is present, probably verify it & bail out if it doesn't pass verification.<br><br>But do I remember correctly that there's now a way to produce the summary without the code itself? (to ship to a thin link step without shipping all the IR) - or is that in an intermediate state for now stripping the debug info because that's easy, but leaving in the (unnecessary) function/global IR? Presumably if not today, eventually, it'd be intended to only ship the summary in that file - in which case there would be no verification possible or required.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><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">3) describe what steps (& how this patch relates) are planned to get to (2)<br></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Charles had a draft patch to dump out the summary in textual form along with the IR from llvm-dis. Peter and Mehdi suggested repurposing/extending the YAML summary dumping (which currently only dumps the type test / devirt summary, and only under certain options and to stdout), to dump the rest of the summary fields and into the llvm-dis output, instead of having an additional dumper.</div><div><br></div><div>As a first step, to avoid the issue of what to do when reading back in via llvm-as, I suggested dumping as LLVM assembly comments (to make it clear it is not parsed back in).</div></div></div></div></blockquote><div><br>It seems good to avoid iterating through multiple formats & corresponding test churn if we can help it with some up-front design discussion.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><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">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?) & now there's an effort to correct that.<br></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Yes</div></div></div></div><div dir="ltr"><div class="gmail_extra"><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"><br>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></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Yep, and Charles's original email here was meant to discuss the desired textual IR dumping format.</div></div></div></div></blockquote><div><br>Cool cool :)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><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">(& 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></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Right, that was Peter and Mehdi's suggestion. It will look a bit different than the rest of the textual IR, but maybe that doesn't matter since this isn't IR.</div></div></div></div></blockquote><div><br>Not sure I'm following quite what you mean by "this isn't IR" - it seems to me like it is IR. It's in-memory, in bitcode, but not in the textual format yet.</div><div><br></div><div> - Dave</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 class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Teresa</div></div></div></div><div dir="ltr"><div class="gmail_extra"><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"><br>- Dave<br><br><div class="gmail_quote"><div><div class="m_8119124852166602078h5"><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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_8119124852166602078h5"><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>
</blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div><br></div>-- <br><div class="m_8119124852166602078gmail_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></blockquote></div></div>