[LLVMdev] Extending AsmPrinter

[David Greene]

On Friday 17 August 2007 13:17, Chris Lattner wrote:
> On Fri, 17 Aug 2007, David Greene wrote:
> >> Posix is pretty available, what system doesn't have them?
> >
> > Windows, for one.  If POSIX is ok, it's better in my mind to just
> > directly
>
> Windows has POSIX calls.

Ok, I'll admit I don't know a lot about what's available there.  I'm going off 
previous experience where POSIX was a pain.  If that's changed, great!

> I don't think open/write etc are POSIX.  Windows has them but you have to
> use different headers etc to get access to them.  I am no expert in this
> area though.

% man open
NAME
       open, creat - open and possibly create a file or device
[...]
CONFORMING TO
       SVr4, SVID, POSIX, X/OPEN, BSD 4.3.   [...]

> I'm not suggesting using iostreams.  I'm suggesting using FILE*'s
> directly.

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:

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.

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

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.

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

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.

Of course, all to be evaluated through benchmarking.

                                                  -Dave