[LLVMdev] Extending AsmPrinter

[Chris Lattner]

On Wed, 15 Aug 2007, David Greene wrote:
>> 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.

Nifty.

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

The syntax used doesn't depend on the underlying implementation 
methodology.  It would be straight-forward to define a new 
"formated_ostream" (or whatever) that uses operator<< etc, but that isn't 
actually implemented in terms of ostreams :)

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

Yep.

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

Hey, I've heard of that... do people really use it?  ;-)

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

The time this matters is during -O0 compilation, when you do no 
optimization.  Compile time is incredibly important because -O0 compiles 
directly impact the edit/compile/debug turn-around cycle.

> Right now the custom streambuf is only used to print asm.  I don't see a
> reason to use it elsewhere.

It sounds very handy to me for a number of things.  :)  Even tablegen and 
the CBE could use it to produce nicer generated code.  We could use is in 
the .ll printer to line up the #uses comments in the .ll file, etc.  For 
it to really be widely usable though, it would have to be very efficient.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/