<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 13, 2017 at 1:27 PM Teresa Johnson via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@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 class="gmail_extra"><div class="gmail_quote">On Mon, Jun 12, 2017 at 3:08 PM, Chandler Carruth via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class="m_-1151181379249149415gmail-"><div dir="ltr">On Mon, Jun 12, 2017 at 1:50 PM Mehdi AMINI via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-06-12 13:04 GMT-07:00 Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Jun 12, 2017 at 12:59 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Jun 12, 2017 at 12:20 PM Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 12, 2017 at 12:16 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span><div dir="ltr">On Mon, Jun 12, 2017 at 12:13 PM Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I think we should start with this patch so that we aren't forced to go further in what I hope is clearly the wrong direction.</div></blockquote></span><div><br>I'm not sure what you mean - it feels to me like this patch is "going further in what is clearly the wrong direction" - a direction that's adding workarounds by providing dumping features instead of roundtrippable .ll syntax?<br></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I don't necessarily agree that this is the wrong direction or a workaround, which is why I think we should discuss it in parallel.</div></div></div></div></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><div><br>This has already slipped further than is ideal - when bitcode support was added for summaries, .ll support should've been provided at the same time, as with any other bitcode feature in LLVM. This is a baseline requirement for features in LLVM's bitcode that seems to have been missed during the initial support/code review.<br><br>When YAML support was added for reading summaries, that would've been a great opportunity to go back and address this missing functionality.<br><br>Now that dumping support is needed/being added, there's another opportunity to go in that direction rather than continuing to work further away from it.<br></div></div></div></blockquote><div><br></div><div>FWIW, just as textual serialization/de-serialization as part of the textual IR was a critical component of preserving use-list order (in addition to the bitcode support), I think the same is true for summaries.</div><div><br></div><div>I'm perfectly happy to keep them *semantically* distinct from the IR (and in a distinct in-memory representation) for now, as that really is a separate concern as Mehdi has pointed out in other contexts.</div><div><br></div><div>But the basic properties of serialization/de-serialization, being able to round trip, and write self-contained test cases should always be common between bitcode and textual IR. The fact that summaries have drifted here should be corrected sooner rather than later, and insisting upon that before going further down the path seems a very reasonable step to ensure we get the right thing long-term.</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I see two main paths:</div><div><br></div><div>1) We iron down the right final format for the .ll and implement it. In the meantime we don't have a good flow to write tests with summaries.</div><div>2) We already have a serialization/deserialization in YAML, why not using it as a starting point? That was introduced to be able to write testing without depending on getting the right final format to achieve `llvm-dis | llvm-as` (i.e. Peter didn't want to hammer down the right .ll format or wait for it).  We could use this to "bootstrap" by injecting it in the .ll somehow, and progress as incremental steps from there to a better .ll format. Knowing that the YAML is machine readable and so can be upgraded to whatever futur .ll format, so we'll be able to convert to it automatically and there isn't much debt involved.</div><div><br></div><div>Unless someone wants to drive very actively 1), it seems pragmatic to me to go with 2) to not block/hinder progress on getting better testing on LTO/ThinLTO summaries.</div></div></div></div></blockquote><div><br></div></span><div>My problem is that, as you say, we already unblocked progress without getting #1 done.</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I'm not sure we have unblocked progress - without this patch to llvm-lto2 there isn't a general way to invoke the existing YAML summary dumper (i.e. other than from the LowerTypeTests pass and the like). It would be nice to get this patch in so we can at access that more easily, given its existence. </div></div></div></div></blockquote><div><br>I /think/ Chandler meant that progress has been unblocked a few times now (when the initial feature was landed without .ll support to match .bc support, and when the YAML support was added instead of .ll support) & still the .ll support hasn't manifested.<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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> I think we need to push harder to actually get #1 as folks haven't actually come back to pay down this technical debt even after making short-term progress.</div><div><br></div><div>(I also agree with David that I don't see any particular reason this would be intractably slow.)</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The initial RFC Charles sent a couple weeks back (Subject: " [RFC][ThinLTO] llvm-dis ThinLTO summary dump format") has a proposed format (not YAML) for the .ll files. Peter had responded that we should have a single dumper (which right now is YAML). PTAL at the initial email he sent there as that was supposed to be the starting point for a discussion about the right long term format for the LLVM assembly.</div></div></div></div></blockquote><div><br>Ah - thanks for bringing this up, it may be better to have the discussion there (well, except a bunch of it's now here too).<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 class="gmail_extra"><div class="gmail_quote"><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div><br></div>-- <br><div class="m_-1151181379249149415gmail_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:2px solid rgb(213,15,37)">Teresa Johnson |</td><td nowrap style="border-top:2px solid rgb(51,105,232)"> Software Engineer |</td><td nowrap style="border-top:2px solid rgb(0,153,57)"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap 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-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</blockquote></div></div>