[LLVMdev] C embedded extensions and LLVM

Ted Kremenek
Sun, 11 Nov 2007 16:13:10 -0000

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.