<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 24, 2014 at 7:53 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> 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>
</span>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>
<span class=""><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>
</span>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>
<span class=""><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>
</span>We can probably add a note saying "newer or corrupt BC".<br></blockquote><div><br></div><div>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.</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">
<span class=""><br>
> Proposed solution:<br>
><br>
> Whether to emit a bitcode wrapper becomes a target-dependent predicate.<br>
<br>
</span>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<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<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><br>
</div></div></blockquote></div><br></div></div>