[llvm] r234535 - Simplify use of formatted_raw_ostream.

[Mehdi Amini]

> On Jun 11, 2015, at 2:56 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
>>> That still puts the output in a file and will buffer the same.
>> 
>> llvm-mc conditionally buffers the output based on:
>> 
>> 
>>    if (!Out->os().supportsSeeking()) {
>>      BOS = make_unique<buffer_ostream>(Out->os());
>>      OS = BOS.get();
>>    }
>> 
>> Redirecting to a file is not the same from the producer point of view, my thought was that stdout would not “supportsSeeking()“ and llvm-mc would add the buffering.
> 
> Yes, but with "-o - > foo", supportSeeking returns true for stdout.

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.

> 
> 
>>> BTW, at which point do you need to access the generated assembly?
>>> Could MCAsmStreamer::FinishImpl flush the stream?
>> 
>> When PassManager.run() finishes I expect my stream to be populated. If MCAsmStreamer::FinishImpl is called at the end of the process, that’s fine with me.
> 
> It should be. Can you give that a try? A patch doing that LGMT since
> it is quite a bit less invasive than switching the buffering.

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

— 
Mehdi