[LLVMdev] Extending AsmPrinter

David Greene dag at cray.com
Wed Aug 15 09:34:04 PDT 2007


On Wednesday 15 August 2007 11:32, Chris Lattner wrote:

> > I'm trying out a few interesting things here based on custom streambufs.
> > It requires some surgery to AsmPrinters as a std::ostream won't work
> > anymore due to the enhanced functionality of the custom streambufs.
> > Is this still interesting to the larger LLVM community?  One thing I have
> > to do is figure out how to handle asm dumps to cerr.
>
> It really depends on what you mean.  I've found that iostreams are
> extremely slow, much slower than C stdio streams.  Eventually I'd like to
> move them to stdio, not to more complex streambufs :)

Basically, what I've done is augment basic_streambuf to keep track of
columns and provide manipulators that use this ability to set the output
at a specific column (by padding with spaces if necessary).  This makes
it easy to line up comments, for example.

This would be quite a bit uglier with C stdio.  For example:

// Custom streambuf (pseudo-llvm APIs)

instr->print(O);
O << comment("Place after instruction");

// C stdio

int current_column = instr->print(outfile);
printComment(current_column, "Place after instruction");

This means that every ::print/::dump/etc API that's used to print asm has to 
track columns by parsing output strings and looking for newlines and tabs.  
With a custom streambuf it's automatic.

There's value to this whole newfangled encapsulation thing.  :)

As for performance, I guess I haven't seen a huge issue.  The compilation
time is spent in the optimization, not in the asm output.

Right now the custom streambuf is only used to print asm.  I don't see a
reason to use it elsewhere.  Of course, other kinds of custom streambuf
can be useful.  I once wrote a circular-buffering streambuf that was great
for dumping debug output.  At program termination the streambuf dumped
that last N lines of output sent to it.  So you didn't get gobs of debug 
output when all you really cared about was what happened toward the end.

                                        -Dave



More information about the llvm-dev mailing list