<div dir="ltr">It stops being a "stream" when you add the ability to write at a specified offset. It's like adding operator+= to something with "outputiterator" in the name. Is there a reason that this has to live inside raw_ostream?<div><br></div><div><div>-- Sean Silva</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 8, 2015 at 3:56 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I noticed that object writer are somewhat convoluted because they have<br>
to write to streams with to seek or pwrite support. For that to work<br>
they have to do a pass over the data computing the size and only then<br>
write it out.<br>
<br>
That is a bit silly, as most of the time (and the ones we care about<br>
performance) we are writing to an actual file with seek support.<br>
<br>
When that is not the case, we can accumulate the data and write it on the end.<br>
<br>
For accumulating the data, raw_svector_ostream works just fine, except<br>
that it doesn't support seeking. Adding that is doable, but<br>
complicates a performance critical structure.<br>
<br>
Fortunately, adding pwrite to raw_svector_ostream is trivial.<br>
<br>
The attached patch changes ELFObjectWriter.cpp to use pwrite to update<br>
the one forward reference that is left at that point. Similar cleanups<br>
should be possible for the other object writers.<br>
<br>
The patch also adds a virtual pwrite to raw_stream and a helper class<br>
for creating a raw_svector_ostream when a given FD does'n support<br>
seeking (like a pipe).<br>
<br>
It passes check-llvm with the exception of<br>
CodeGen/R600/cf-stack-bug.ll which uses "2>&1" and depends on the<br>
order the data from stdout and stderr is mixed.<br>
<br>
The test could be fixed, but another issue is that clang is structured<br>
to pass a plain raw_ostream around until the last moment when it is<br>
wrapped in a formatted_raw_ostream. That makes it harder to detect if<br>
a stream supports seeking or not.<br>
<br>
So, if you guys are OK with this direction, I think the proper way to<br>
split/commit this is<br>
<br>
* Implement classof for raw_ostream.<br>
* Stop using formatted_raw_ostream when producing binaries.<br>
* This patch, but SeekWrapper can then take a plain raw_stream and use<br>
dyn_cast to see if it a fd stream. It would also not add pwrite to<br>
formatted_raw_ostream.<br>
<br>
Cheers,<br>
Rafael<br>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>