[LLVMdev] Extending AsmPrinter

Chris Lattner sabre at nondot.org
Fri Aug 17 15:01:46 PDT 2007


On Fri, 17 Aug 2007, David Greene wrote:
> Ah.  Basically operator<< for FILE*.  I don't see a lot of benefit to
> redefining operator<< for every type just to avoid ostreams.  The
> problem isn't basic_ostream _per_se_.  There are two issues we're
> worried about:

The problem is basic_ostream and the design of the whole iostreams 
library.  Use of virtual base classes makes every virtual method 
particularly expensive, for example.

> 1. The static constructor contortions in place to handle the extremely
>   unlikely case of a static object constructor writing to one of the
>   standard streams.

I also dislike this strongly, but it isn't really related.

> 2. Slowness of std::cout and friends due to their reliance on FILE * 
>    buffering and resulting excessive virtual function calls.

Use of FILE* is not the issue, virtual functions are.

> I just implemented "standard" AsmStreams (the name for my custom streams) to
> handle the cases where we want to dump Asm to standard error.  I just point
> the AsmStreambuf to STDERR_FILENO.  I simply avoid the constructor issue by
> declaring that no user shall write to an AsmStream in a static object
> constructor.  So we don't have worries about multiple constructor calls at
> program startup.  There is no ios_base::Init equivalent for AsmStream.

This gives you the virtual overhead of streams without the buffering 
overhead of FILE*.  Instead of the buffering overhead of stdio you have 
your own different but exactly equivalent buffering overhead.

> The second concern is addressed as described earlier.  I do the buffering
> at the AsmStream level to minimize virtual calls.

How is this different than buffering done by stdio?

> This will still be slightly slower than raw FILE * or POSIX calls because
> there will be some virtual function call overhead.  But it should be much
> better than standard streams and we get all of the nice benefits of iostreams.

The only problem you seem to have solved is avoiding having to define a 
few operator<<'s, this doesn't seem like a very good tradeoff to me.

-Chris

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



More information about the llvm-dev mailing list