[LLVMdev] C embedded extensions and LLVM

[Gordon Henriksen]

On Nov 11, 2007, at 02:07, Christopher Lamb wrote:

> I've been playing around with clang/LLVM looking at adding partial  
> support for the draft technical report for embedded C extensions  
> (TR18037, http://www.open-std.org/jtc1/sc22/wg14/www/docs/ 
> n1169.pdf), specifically named address spaces.
>
> Named address spaces need to be tracked in LLVM in essentially all  
> the same places that alignment is tracked, which necessitates adding  
> the information to the .bc format. Given the Apple has shipped .bc  
> files I'm guessing that backwards compatibility is very important.  
> Given this and the work I see happening on using the newish  
> serialize/deserialize infrastructure what is the pattern for  
> extending the .bc format in a backwards compatible way? Is it safe  
> to add records to the writer for an instruction and predicate parts  
> of the reader based on the number of records present so that old .bc  
> files with fewer records for that entry should still be able to be  
> read?


It's easy enough to extend a bitcode record in a compatible manner.

   • The writer should place new fields only at the end of a record.  
Earlier readers will ignore them.
   • If a record comes up short, a backwards-compatible default should  
be selected by the reader.

This provides backwards and forwards compatibility, which is great,  
and surprisingly simple to accomplish.

Sounds like you're adding fields to load and store nodes. To reduce  
the cost for programs that do not use memory spaces, you might try to  
optimize the representation by taking advantage of the default value  
when encoding the record.

— Gordon