Reserve a vendor reserved block ID for bitcode

[mehdi_amini]

Summary

The idea is that vendor toolchains can insert a block for their own
internal purpose while generating bitcode that will be compatible
with the open-source tools. The latter just ignoring this block.

We (Apple) intend to use it for versioning the bitcode. The versioning
would not make sense with respect to open-source release since our
internal versions/releases don't align.

[• rafael]

Needs a test showing that it is actually ignored.

Can you expand on how you intend this to be used? We have a documented
policy on supporting old bitcode:

http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility

Is that not what you are looking for?

[mehdi_amini]

Add a test

[alexr]

So, we went through this last year.... http://lists.llvm.org/pipermail/llvm-dev/2014-November/078498.html

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. Bike shed away, but there should be something simple enough at the start that can tell us we're looking at the wrong thing.

[bob.wilson]

Alex, you guys were right. I hadn't thought of all the cases we would need to check for. I agree that we should have a simple mechanism to distinguish content from different vendors.

include/llvm/Bitcode/LLVMBitCodes.h

enum BlockIDs {
 
     // Module sub-block id's.
     PARAMATTR_BLOCK_ID,
     PARAMATTR_GROUP_BLOCK_ID,
 
     CONSTANTS_BLOCK_ID,
     FUNCTION_BLOCK_ID,
 
-    UNUSED_ID1,
+    // Valid inside vendor specific toolchains only, discarded by open-source
+    VENDOR_RESERVED_ID,
 
     VALUE_SYMTAB_BLOCK_ID,
     METADATA_BLOCK_ID,
     METADATA_ATTACHMENT_ID,
 
     TYPE_BLOCK_ID_NEW,
 
     USELIST_BLOCK_ID

test/Bitcode/vendor_block.test

+# Check that a global vendor block is correctly ignored 
+# and skipped by the vanilla bitcode reader
+
+; RUN: opt -S %p/Inputs/vendor_block.bc | FileCheck %s
+; CHECK: target triple = "x86_64-apple-macosx10.9"
+