<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 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@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;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@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"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi Sean,<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">> Rafael gave me some of the backstory on this. Basically it is to work around some buggy behavior in the Darwin ar. Adding that on the front of the bitcode file just to get a version doesn't seem
<o:p></o:p></p>
<p class="MsoNormal">> like a very clean thing to do.<o:p></o:p></p>
<p class="MsoNormal">> <o:p></o:p></p>
<p class="MsoNormal">> Doug, what other alternatives did you guys consider before settling on this?<o:p></o:p></p>
<p class="MsoNormal">> <o:p></o:p></p>
<p class="MsoNormal">> As for #2 above, the non-universality of the wrapper makes using the wrapper as a version indicator sort of a non-starter.<o:p></o:p></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">Using the bitcode wrapper was our main idea as we discovered it fairly early one when looking for ways to store the version information. Originally we wanted
to propose adding extra fields at the end of the bitcode wrapper, but we found that we only needed the version to be embedded by the compiler, and the wrapper already included an unused version field, so we were hoping to use that. We also liked that the existing
bitcode wrapper was documented, implemented and already worked with most if not all of the existing LLVM tools.<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">One alternative that was suggested was we could create a version section in the bitcode that the compiler would then embed the version into. But we did not
want to take that approach because it would have required the linker to parse the bitcode to just to extract the version. That functionality is not available (to my knowledge) in our proprietary linker. By using the bitcode wrapper, our linker is easily able
to extract the version and find the bitcode without needing to understand bitcode at all.<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">The non-universality of the wrapper could be an issue, but we were going to work around that by forcing our compiler to always produce the bitcode wrapper for
our target, so in our case that would not be an issue. If versioning of bitcode files is something that might be useful to other teams, it might make sense to just apply it on all bitcode files produced by the compiler. In essence, make it required instead
of optional as it currently stands. The bitcode wrapper would only add 20 bytes to the size of the file and most LLVM tools should be able to handle them without any changes.<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">Douglas Yung<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>
<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> Friday, October 31, 2014 21:13<br>
<b>To:</b> llvmdev@cs.uiuc.edu<br>
<b>Cc:</b> Yung, Douglas<br>
<b>Subject:</b> Re: Using the unused "version" field in the bitcode wrapper (redux)<o:p></o:p></span></p>
</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 Fri, Oct 31, 2014 at 6:21 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal">Hi all,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Doug Yung started a discussion earlier (<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-September/077227.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-September/077227.html</a>) about using the unused "version"
field in the bitcode wrapper, and I think there was some misunderstanding. I'd like to clarify the motivation.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The reason we want to add the version field is to easily identify "old" bitcode. It is only LLVM version granularity, but that is good enough for us. The obvious thing is that we offer compatibility, so why do we need to know the bitcode
version? There are really two reasons:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">1. In the short term, LLVM does theoretically provide compatibility. However, we at Sony are under a much stronger commitment to our customers than the open source project here, so until the test infrastructure is beefed up quite a bit
to improve this confidence in the backwards compatibility promise, the version field is a quick unobtrusive way for us to behave correctly in the short term. Beefing up the compatibility testing is a separate discussion that everybody realizes is a much larger
long-term endeavor; we at Sony are glad to help with that. As we prepare for our first official SDK release with LTO, where our customers are officially sanctioned to feed bitcode to our tools, a solution is needed though. I think that existing toolchains
with LTO will also benefit from this in the near-term.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">2. In the long term, it *will* break across major releases. Currently I don't think we have a way to identify this. This is a bit longer-term perspective, but it will eventually come up and this fixes it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">Also, is there a reason why the bitcode wrapper is Darwin-specific?<o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Rafael gave me some of the backstory on this. Basically it is to work around some buggy behavior in the Darwin ar. Adding that on the front of the bitcode file just to get a version doesn't seem like a very clean thing to do.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Doug, what other alternatives did you guys consider before settling on this?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">As for #2 above, the non-universality of the wrapper makes using the wrapper as a version indicator sort of a non-starter.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Looks like I've taken my second U-turn on this proposal :/<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><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">
<div>
<div>
<div>
<p class="MsoNormal">Can we just always use it and simplify the code path?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888">-- Sean Silva<o:p></o:p></span></p>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>