<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-06-07 10:01 GMT-07:00 Mehdi AMINI <span dir="ltr"><<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>></span>:<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 class="">2017-06-07 9:44 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_-3743830175131875040gmail-"><div dir="ltr">On Tue, Jun 6, 2017 at 2:21 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-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_-3743830175131875040gmail-m_-3458806816444429001m_-203227576041730874gmail-"><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></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></div></div><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"><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></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></div></div></blockquote></span><div><br>What I'm suggesting is that this is an (optional) IR feature as much as any other</div></div></div></blockquote><div><br></div></span><div>Well I disagree with this at this point, because I haven't read anything that would support it.</div><div>I'd be happy to revise my position if you were providing any argument that would make this holds in face of any other analysis result.</div><span class=""><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> - so it seems slightly odd that it'd be YAML rather than something that looked more like the rest of the IR. Though I'm not outright opposed to YAML here - just want to make sure this information is being treated as a first class IR construct (as much as use order, comdats, etc are for rough examples)<br></div></div></div></blockquote><div><br></div></span><div>YAML was pushed forward as an easy way to get there IIRC. It wasn't set in stone and it was clearly open to change it to a more integrate format. </div><div>So I'm supportive of anyone who would replace this with a more "textual-IR integrated" format, I haven't proposed this in this thread because Teresa is interested in getting something readable "quickly". My point was more that as an intermediate step, I rather reuse the existing YAML serialization than creating yet another dump.</div><span class=""><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></div><span class="m_-3743830175131875040gmail-"><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"><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>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></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Yes conceptually they can be standalone.</div></div></div></div></blockquote></span><div><br>This seems to provide the strongest/clear motivation for having summaries as a first class (though optional) IR construct.<br></div></div></div></blockquote><div><br></div></span><div>No, this provide a strong motivation to have a proper serialization, I don't see how you connect this to the rest of the IR.</div><span class=""><div><br></div></span></div></div></div></blockquote><div>On the topic of how it is / isn't part of the IR: given a Module or Function you can't get a summary. It lives on the side in the bitcode, but there isn't any connection in memory: it is purely an analysis result that is serialized for convenience.</div><div><br></div><div>Note that we considered attaching it to the Module, however it causes problem around invalidation (like every analysis result, this is a "view" of the IR at a given point, changing the IR invalidates it). </div><div><br></div><div>-- </div><div>Mehdi</div><div><br></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"><span class=""><div></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></div><span class="m_-3743830175131875040gmail-"><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"><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"><span class="m_-3743830175131875040gmail-m_-3458806816444429001m_-203227576041730874gmail-"><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"><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></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>llvm-dis does not display summaries today, so you can't just use llvm-dis like a "regular" flow.</div></div></div></div><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"><div class="gmail_quote"><div>How are they inspected today?<br></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>llvm-bcanalyzer? And now the YAML dump as well.</div></div></div></div><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"><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></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The IR already contains all the information, so why repeating it? </div></div></div></div></blockquote></span><div><br>For the same reason that it's relevant to test cases which way it's encoded, etc (in the same way that the LLVM IR repeats types of uses, for example - even though they're totally redundant from a "does this have all the semantic information required) & because it can be standalone.</div></div></div></blockquote><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_-3743830175131875040gmail-"><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>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></div></div></blockquote></span><div><br>Ah, sorry, I'm not suggesting it should be required - in the same way it's not required in the bitcode. But if you want a summary in the bitcode when assembling a .ll file it seems OK To say you write it in the IR, </div></div></div></blockquote><div><br></div></span><div>No it does not seem OK to me to write summaries alongside the IR in tests in general (outside of specific need like testing the round-trip of course). </div><div>It is entirely redundant and I don't perceive any benefit, I don't see why you would want to do that?</div><span class=""><div><br></div><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>and equally if there is a summary in the bitcode it seems reasonable that it be printed in the .ll file by llvm-dis.<br></div></div></div></blockquote><div><br></div></span><div>I agree and I advocated for this earlier.</div><span class=""><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_-3743830175131875040gmail-"><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>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.<br></div></div></div></div></blockquote></span><div><br>I'm not sure I understand - you mean for executions of tools that don't need the rest of the IR, there could be a different/separate tool that consumes YAML summaries and produces YAML </div></div></div></blockquote><div><br></div></span><div>It does not have to be a separate tool: a tool that is looking to operate purely on summary should just ask to get the summaries out of the input file. The input being textual or bitcode shouldn't matter much at this point. </div><div>This is exactly how 'opt' and 'llc' operate.</div><span class=""><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>summaries and that would be tested - but the "consuming a summary in a bitcode file" would not be?<br></div></div></div></blockquote><div><br></div></span><div>This is exactly what we're doing with (almost) *all* of the .ll test: we write them as textual, and read them back as textual, and not as bitcode.</div><span class=""><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>I'm not sure I understand the benefit of this separation and asymmetry with the bitcode form of the same data.<br></div></div></div></blockquote><div><br></div></span><div>Have you tried to write a test directly in bitcode? ;)</div><div><br></div><div>I'm not sure we're talking about the same thing right now.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div> </div></font></span></div></div></div>
</blockquote></div><br></div></div>