[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