[LLVMdev] C embedded extensions and LLVM

[Chris Lattner]

>>> Please add a generous block comment to
>>> llvm/include/llvm/Bitcode/LLVMBitCodes.h above the new enum  
>>> explaining
>>> what the difference is though. :)
>>
>
> Should have said:
>
>> Should I take the same approach to the encoding of pointer types in  
>> the types table?

PointerTypes are a bit easier.  The code to write them looks like this:

     case Type::PointerTyID:
       // POINTER: [pointee type]
       Code = bitc::TYPE_CODE_POINTER;
       TypeVals.push_back(VE.getTypeID(cast<PointerType>(T)- 
 >getElementType()));


The code to read them look like this:

     case bitc::TYPE_CODE_POINTER:   // POINTER: [pointee type]
       if (Record.size() < 1)
         return Error("Invalid POINTER type record");
       ResultTy = PointerType::get(getTypeByID(Record[0], true));
       break;

The interesting point here is that PointerType currently has one field  
(that it push_back's onto TypeVals).  The reader requires this field  
to be present, but ignores any additional fields.  You should just be  
able to add another typeVals.push_back() to the writer, and the  
readers will be transparently compatible with it.  Just make the new  
reader do something like this:

     case bitc::TYPE_CODE_POINTER:   // POINTER: [pointee type]
       if (Record.size() < 1)
         return Error("Invalid POINTER type record");
       unsigned AddrSpace = Record.size() >= 2 ? Record[1] : 0;
       ...

-Chris