<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<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"><o:p></o:p></span></p>
<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?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">And that's just one example 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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></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"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></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. 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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></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:chisophugis@gmail.com]
<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; llvmdev@cs.uiuc.edu<br>
<b>Subject:</b> Re: [LLVMdev] Using the unused "version" field in the bitcode wrapper (redux)<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></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:<o:p></o:p></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".<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-- Sean Silva<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></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<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">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><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>