<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 22, 2014 at 2:15 AM, James Courtier-Dutton <span dir="ltr"><<a href="mailto:james.dutton@gmail.com" target="_blank">james.dutton@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">On 22 June 2014 01:18, Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:<br>

> Does anyone have anything else to say about .bc/.ll compatibility? It is<br>
> important to be clear to users about what compatibility we provide. I'd like<br>
> to get consensus about this and put it in the docs somewhere.<br>
><br>
> -- Sean Silva<br>
><br>
<br>
</div>To make this all a bit easier, how about making clang/llvm output a<br>
version number at the beginning of the .ll or .bc file?<br>
It would then be clear which version of clang/llvm wrote the file out.<br>
You could then add warnings if clang/llvm thought they were<br>
incompatible with the older version or not.<br></blockquote><div><br></div><div>I don't think that would significantly help.<br><br>For .bc, the sizes of records already implicitly hold that information in a more fine-grained and semantic way (not tied to versions, but rather intrinsically to the change to the IR).<br>
</div><div>For .ll, it is too easy to end up with a file that has an nonexistent or inconsistent version number (such as a hand-written file) so we wouldn't be able to rely on it.<br><br></div><div>Anyway, that's sort of a separate discussion. For now, I'd like to focus strictly on deciding what guarantees we offer.<br>
<br></div><div>-- Sean Silva<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Kind Regards<br>
<span class=""><font color="#888888"><br>
James<br>
</font></span></blockquote></div><br></div></div>