<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 24, 2014 at 7:00 PM, Robinson, Paul <span dir="ltr"><<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div><span class="">
<p class="MsoNormal" style="margin-left:.5in">It should report that the<br>
particular new feature is not support. In this case, something like<br>
"unknown 'g' flag in datalayout".<br>
<br>
<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
</span><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Currently that would hit an llvm_unreachable(). How should we re-engineer this to provide sensible error recovery in an LTO context, while continuing to provide
the die-horribly fallback behavior that it currently (quite reasonably) provides in all other contexts?</span></p></div></div></blockquote><div><br></div><div>That is just a bug and has nothing to do with LTO or compatibility. We should never hit llvm_unreachable due to a bad input. In release builds llvm_unreachable turns into nasal demons.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">And that's just one example</span></p></div></div></blockquote><div><br></div><div>Please provide another. The above example is invalid w.r.t. LTO or compatibility so it is hard to see your point from it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> of a place that would have to be re-engineered this way, to provide the necessary degree of future-proofing across some indeterminate
number of modules within LLVM that never expected to see this particular problem.
<u></u><u></u></span></p><span class="">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal" style="margin-left:.5in">Again, *any* solution involving the bitcode wrapper is not interesting<br>
to the open source project since it is not required.<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
</span><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I fail to see why all that re-engineering effort IS "required" to support the use-cases we've provided, and why future-proofing a large body of software that
quite honestly was never designed for it and has genuinely very few reasons why it should be.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">If we're going to support bitcode as a long-term storage format, everything that pulls information out of bitcode MUST be future-proofed. Doing it piece by
piece is a LOT of engineering effort to make LLVM user-friendly in this way; it was never intended to have that degree of self-defense.</span></p></div></div></blockquote><div><br></div><div>I don't understand what you mean by "future-proofed" in this context. If you mean "never crash on bad user input", then your point doesn't make sense to me. LLVM is engineered to never crash on bad user input in the same sense that it is engineered to correctly compile code; neither is allowed, and if either happens it is a bug.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> The wrapper provides that as a simple low-cost high-reliability mechanism, and allows the LLVM community to continue not
having to worry about future-proofing. It adds the necessary layer that provides the necessary protection, to those very few vendors who actually need this kind of feature. And it costs *nothing* for anyone else, because nobody else will actually have the
wrapper.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">If you're asserting that "bitcode as a long-term storage format" has been completely rejected by the open source project, well, that's a different statement,
and not one that I have been hearing.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Sony is definitely moving in the direction of supporting bitcode as a long-term format, therefore we DO require future-proofing, and the wrapper is the cheapest
engineering solution to get that.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--paulr<u></u><u></u></span></p>
<p class="MsoNormal"><a name="149e4e529d2fa76e__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Sean Silva [mailto:<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>]
<br>
<b>Sent:</b> Monday, November 24, 2014 4:19 PM<br>
<b>To:</b> Rafael Espíndola<br>
<b>Cc:</b> Robinson, Paul; Bruce Hoult; Yung, Douglas; <a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a><br>
<b>Subject:</b> Re: [LLVMdev] Using the unused "version" field in the bitcode wrapper (redux)<u></u><u></u></span></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Mon, Nov 24, 2014 at 7:53 AM, Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>> wrote:<u></u><u></u></p>
<p class="MsoNormal">> Right, that version number is used to resolve *ambiguities* in how to<br>
> interpret some chunk of bitcode. It is not a generic bitcode version<br>
> scheme, because most bitcode format changes involve things like adding<br>
> new operands or opcodes, which are easily identified without needing<br>
> an explicit version number.<br>
<br>
That is what it is used for at the moment. It is is just a number, we<br>
can increment it as often as we want.<br>
<br>
> The scenario I am most concerned about is this:<br>
><br>
> - We as a vendor publish toolchain #12 based on SVN r250000.<br>
> - During subsequent LLVM development, changes happen (!).<br>
> For example, a new key letter 'g' in the Data Layout. This is<br>
> not a bitcode ambiguity so MODULE_CODE_VERSION is unchanged.<br>
> - We as a vendor publish toolchain #13 based on SVN r300000.<br>
> - Some middleware provider publishes libIncrediblyUseful.bc built<br>
> using spiffy new toolchain #13.<br>
> - Some hapless game developer tries to use libIncrediblyUseful.bc<br>
> but is still on toolchain #12. This causes an error during some<br>
> LTO build phase, of course; the question is, what kind of error<br>
> and how does Hapless Game Developer know what to do?<br>
<br>
In summary. An old tool reading new bitcode. It should report that the<br>
particular new feature is not support. In this case, something like<br>
"unknown 'g' flag in datalayout".<br>
<br>
> This does *nothing* for Hapless Game Developer. HGD wants to see<br>
> "this bitcode file was generated by a newer version, I don't understand<br>
> how to interpret it" because _that's_ the actual problem.<br>
<br>
We can probably add a note saying "newer or corrupt BC".<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">This makes sense to me. I think it is pretty safe to assume that any "invalid bitcode" that an end-user would get their hands on is just because the bitcode is from a newer version.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">-- Sean Silva<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
> Proposed solution:<br>
><br>
> Whether to emit a bitcode wrapper becomes a target-dependent predicate.<br>
<br>
Again, *any* solution involving the bitcode wrapper is not interesting<br>
to the open source project since it is not required.<br>
<br>
Cheers,<br>
Rafael<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div></div></div>
</div>
</div>
</blockquote></div><br></div></div>