<div dir="ltr">I'm afraid I'm not exactly sure where we left off here, but I'll try to reboot the discussion a bit.<div><br></div><div>I see two problems that we really should solve:</div><div><br></div><div>1) Bitcode from an old major version has a real chance of actually being parsed by a new LLVM and having different, wrong meaning. This is especially true right around the X.1 releases where we've removed a bunch of auto-upgrade functionality. I think we should have a *strong* defense against this, and that the correct way of doing it is to encode the "epoch" of bitcode, and reject unsupported epochs with a clear diagnostic. We'll usually only accept a single epoch, and for X.0 releases we'll support two.</div><div><br></div><div>2) Within a bitcode epoch, we might have bitcode from a *future* LLVM with some incompatible change, or we might have temporary bugs in the bitcode (oops, I changed an enum used in the bitcode and it hasn't been reverted yet). I think this was Mehdi's original motivation. The more I think about it, the more I like a simple and non-prescriptive approach here. I think the more complex ideas (including my own) aren't that likely to work, and are likely to be a lot of effort relative to the value provided. My suggested simple approach is essentially what Alex and others have described: a string field which is used to identify the producer of bitcode, so that *when the reader hits an error*, it can print out this human readable identification of the producer. This could contain the '--version' output or something similar. I think *enforcing* that these match (or even exist) isn't really useful because it makes it hard to write bitcode tests ore otherwise do things that would otherwise work today. I think it should be limited to just a diagnostic aid for humans.</div><div><br></div><div><br></div><div>Do these two changes make sense?</div><div><br></div><div><br></div><div>If so, I suggest we add support for writing #1 now at 0, and verify in the reader that it either is missing or zero. With 4.0 we can increment it to epoch 1, and with 4.1 we can remove support for either 0 or missing.</div><div><br></div><div>And I suggest adding the optional identification string, and filling it out with the version information when using Clang or the basic tools.</div><div><br></div><div><br></div><div>This seem like a reasonable path?</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 16, 2015 at 3:31 PM Alex Rosenberg via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, something like that. I don't feel a need to bikeshed the shape of it, but it should be documented and vendor IDs of whatever form should be assigned/committed into the source. I'd suggest that each vendor get only one ID and subsequent data be used to differentiate internal cases. We will want to discourage cowboy corporations just picking their own IDs and not registering them with the project.<br>
<br>
Alex<br>
<br>
> On Sep 17, 2015, at 2:39 AM, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>> wrote:<br>
><br>
><br>
>> On Sep 10, 2015, at 7:47 PM, Alex Rosenberg <<a href="mailto:alexr@leftfield.org" target="_blank">alexr@leftfield.org</a>> wrote:<br>
>><br>
>> alexr added a subscriber: alexr.<br>
>> alexr added a comment.<br>
>><br>
>> So, we went through this last year.... <a href="http://lists.llvm.org/pipermail/llvm-dev/2014-November/078498.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2014-November/078498.html</a><br>
>><br>
>> If we add a vendor block, we should at a minimum define a way to identify which vendor it is, in case we are handed bitcode from somewhere else.<br>
>> Bike shed away, but there should be something simple enough at the start that can tell us we're looking at the wrong thing.<br>
><br>
><br>
> The way I do it internally right now is by using a “magic” at the beginning of the block. We could ask “by convention” implementer to always write a (32bits?) unique id at the beginning of the block, but it would be up to the vendor to follow this convention. Does this match what you have in mind?<br>
><br>
> ―<br>
> Mehdi<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</blockquote></div>