<div dir="ltr"><br><div class="gmail_extra"><br><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: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><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>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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"> & now there's an effort to correct that. </div></blockquote><div><br></div><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> -- </div><div>Mehdi</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">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="h5"><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="h5"><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:<wbr>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 class="">
______________________________<wbr>_________________<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/<wbr>mailman/listinfo/llvm-dev</a><br>
</span></blockquote></div></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">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/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>