[LLVMdev] C embedded extensions and LLVM

[Ted Kremenek]

On Nov 10, 2007, at 11:07 PM, Christopher Lamb wrote:

>  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?

FYI, there are no current plans to replace the implementation of the  
LLVM bitcode reader/writer with something that uses the new serialize/ 
deserialize infrastructure.  It is possible, however, that it could be  
used as a convenient tool to add new kinds of records to the bitcode.

The serialize/deserialize infrastructure is intended to be another API  
that sits just above the Bitstream reader/writer (which the LLVM  
bitcode reader/writer is built on), and its role is to serialize  
arbitrary objects using logic provided via C++ trait classes.  The  
serializer keeps track of pointers and references (allowing objects  
with multiple pointers to them to be safely and transparently  
serialized, or even cyclic data structures).  The serializer also  
allows almost complete transparency of the underlying bitstream format  
(including the notion of blocks and records), although the goal is to  
provide an interface to those details should the client need it (this  
is gradually taking form).

The serializer's big role right now is to support serialization of  
data structures in the new C frontend.  This includes ASTs, and all  
the supporting meta data needed to serialize out a C program and read  
it back in.  We currently have made a good deal of progress on this  
project.  Thus initially, our goals with the serializer don't have to  
contend with problems of backwards compatibility with an existing  
application.  Our goal is to first get serialization "right" for  
clang, but at the same time it isn't being engineered as an API that  
will only be useful in the new frontend.