[llvm] r234535 - Simplify use of formatted_raw_ostream.

[Rafael Espíndola]

> I didn’t look at the right path in llvm-mc anyway, I looked at the binary code generation and not the ASM one, which is different and never add a buffered stream.
> I’ll try to reproduce your measure and try to buffer outside of formatted_ostream to figure out what is the impact of the virtual method vs lack buffering.

I did check in a debugger that if outputting to a file we use a
raw_fd_ostream and that has a buffer, but it is behind a virtual
interface.

> If a bit less invasive, but it seems a bit “hacky” to me: it's an implicit contract between MCAsmStreamer and its client.
> If we go this way, what about having MCAsmStreamer taking a raw_ostream and wrapping it internally in a formatted_raw_ostream?
>
> Conceptually, the fact that the formatted_ostream forces to use an internal buffer does not sounds very friendly to me, I don’t really see why it can’t just be a transparent wrapper over a stream (performance might be a reason).

I fully agree that it would be cleaner to just have formatted_ostream
be unbuffered and not change the underlaying stream buffer.

Please do benchmark it, I only have my laptop at the moment and no
experience benchmarking on OS X.

I also have no idea if anyone still cares about the performance of
printing assembly now that integrated .o output is mature (I know I
don't :-) ).

Cheers,
Rafael