<div dir="ltr">Hello,<div><br></div><div>Just an update on that. I am personally using -git-commit-after-all *as-is* extremely frequently (combined with "git filter-branch" and "opt -S -instnamer" it is extremely useful).</div><div>I unfortunately won't have time to write a better implementation of that, and I agree "git fast-import" seems the way to go. If anybody is motivated enough to do so, feel free.</div><div><br></div><div>Best regard!</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 22, 2018 at 10:38 AM Reid Kleckner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Obviously, we do not want all stderr output to be buffered. However, I think it would be great to change Function::print and Module::print to call raw_ostream::SetBuffered / raw_ostream::SetUnbuffered before and after printing. I guess if the original stream was buffered we don't want to mark it unbuffered, so we may need to tweak the raw_ostream interface. Looks easy, though.</div><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 22, 2018 at 8:06 AM Fedor Sergeev via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Oh, well... as usually the answer appears to be pretty obvious.<br>
99% of the time is spent inside the plain write.<br>
<br>
-print-after-all prints into llvm::errs(), which is an *unbuffered*<br>
raw_fd_stream.<br>
And -git-commit-after-all opens a *buffered* raw_fd_stream.<br>
<br>
As soon as I hacked -print-after-all to use a buffered stream to stderr<br>
performance went<br>
up to the normal expected values:<br>
<br>
] time bin/opt -O1 big-ir.ll -disable-output -print-after-all<br>
-print-module-scope 2>&1 | grep -c "^; ModuleID"<br>
526<br>
<br>
real    0m2.363s<br>
user    0m2.373s<br>
sys     0m0.271s<br>
]<br>
<br>
So, the morale of this story is - we should not be printing module IR<br>
into dbgs/errs().<br>
<br>
And then the idea of streaming IR module dumps into a buffered stream<br>
and then postprocessing seems<br>
to be a right one.<br>
<br>
regards,<br>
   Fedor.<br>
<br>
On 03/21/2018 01:08 PM, Fedor Sergeev via llvm-dev wrote:<br>
> On 03/16/2018 01:21 AM, Fedor Sergeev via llvm-dev wrote:<br>
> > git-commit-after-all solution has one serious issue - it has a<br>
> hardcoded git handling which<br>
> > makes it look problematic from many angles (picking a proper git,<br>
> > selecting exact way of storing information, creating repository,<br>
> replacing the file etc etc).<br>
> ><br>
> > Just dumping information in a way that allows easy subsequent<br>
> machine processing<br>
> > seems to be a more flexible, less cluttered and overall clean<br>
> solution that allows to avoid<br>
> > making any of "user interface" decisions mentioned above.<br>
> ><br>
> > We need to understand why git-commit-after-all works faster than<br>
> print-after-all.<br>
> Made an interesting experiment today and extended your<br>
> git-commit-after-all to avoid issuing<br>
> any git commands if git-repo starts with "/dev/".<br>
><br>
> With git-repo=/dev/stderr it becomes functionally equivalent to<br>
> print-after-all+print-module-scope,<br>
> dumping module into stderr after each pass.<br>
><br>
> On my testcase:<br>
><br>
> # first normal git-commit-after-all execution<br>
> ] rm -rf test-git; time $RR/bin/opt -O1 some-ir.ll -disable-output<br>
> -git-commit-after-all -git-repo=./test-git<br>
><br>
> real    0m7.172s<br>
> user    0m6.303s<br>
> sys     0m0.902s<br>
> # then "printing" git-commit-after-all execution<br>
> ] time $RR/bin/opt -O1 some-ir.ll -disable-output<br>
> -git-commit-after-all -git-repo=/dev/stderr 2>&1 | grep -c '^; ModuleID'<br>
> 615<br>
><br>
> real    0m2.893s<br>
> user    0m2.859s<br>
> sys     0m0.356s<br>
> # and finally print-after-all<br>
> ] time $RR/bin/opt -O1 some-ir.ll -disable-output -print-after-all<br>
> -print-module-scope 2>&1 | grep -c "^; ModuleID"<br>
> 526<br>
><br>
> real    2m8.024s<br>
> user    0m55.933s<br>
> sys     3m19.253s<br>
> ]<br>
> Ugh... 60x???<br>
> Now, I'm set to analyze this astonishing difference that threatens my<br>
> sanity (while I'm still sane ... hopefully).<br>
><br>
> regards,<br>
>   Fedor.<br>
> PS btw, I checked /dev/null - and it works faster than /dev/stderr as<br>
> expected :)<br>
><br>
> > I dont believe in magic... yet :)<br>
> ><br>
> > And, btw, thanks for both the idea and the patch.<br>
> ><br>
> > regards,<br>
> >   Fedor.<br>
> ><br>
> > On 03/16/2018 12:03 AM, Alexandre Isoard wrote:<br>
> >> If this is faster than -print-after-all we may actually consider<br>
> pushing that in the code base then? (after diligent code review of<br>
> course)<br>
> >><br>
> >> Note that it uses the same printing method as -print-after-all:<br>
> >> - create a pass of the same pass kind as the pass we just ran<br>
> >> - use Module::print(raw_ostream) to print (except -print-after-all<br>
> only print the concerned part and into stdout)<br>
> >><br>
> >> If there is improvement to be done to print-after-all it might also<br>
> improve git-commit-after-all. (unless that only improve speed when<br>
> printing constructs smaller than module)<br>
> >><br>
> >> In any case, it is, to me, much more usable (and extensible) than<br>
> -print-after-all. But requires git to be in PATH (I'm curious if that<br>
> works on Windows).<br>
> >><br>
> >> On Thu, Mar 15, 2018 at 1:35 PM, Daniel Sanders<br>
> <<a href="mailto:daniel_l_sanders@apple.com" target="_blank">daniel_l_sanders@apple.com</a>> wrote:<br>
> >><br>
> >>     Does <a href="https://reviews.llvm.org/D44132" rel="noreferrer" target="_blank">https://reviews.llvm.org/D44132</a> help at all?<br>
> >><br>
> >><br>
> >>>     On 15 Mar 2018, at 09:16, Philip Reames via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> >>><br>
> >>>     The most likely answer is that the printer used by<br>
> print-after-all is slow.  I know there were some changes made around<br>
> passing in some form of state cache (metadata related?) and that<br>
> running printers without doing so work, but are dog slow.  I suspect<br>
> the print-after-all support was never updated.  Look at what we do for<br>
> the normal IR emission "-S" and see if print-after-all is out of sync.<br>
> >>><br>
> >>>     Philip<br>
> >>><br>
> >>>     On 03/15/2018 08:45 AM, Alexandre Isoard via llvm-dev wrote:<br>
> >>>>     Huh. Great! 😁<br>
> >>>><br>
> >>>>     I don't believe my poor excuse from earlier (else we should<br>
> map all pipes into files!), but I'm curious why we spend less time in<br>
> system mode when going through file than pipe. Maybe /dev/null is not<br>
> as efficient as we might think? I can't believe I'm saying that...<br>
> >>>><br>
> >>>>     On Thu, Mar 15, 2018, 08:25 Fedor Sergeev<br>
> <<a href="mailto:fedor.sergeev@azul.com" target="_blank">fedor.sergeev@azul.com</a>> wrote:<br>
> >>>><br>
> >>>>         Well, git by itself is so focused on performance, so its<br>
> not surprising<br>
> >>>>         to me that even using git add/git commit does not cause<br>
> >>>>         performance penalties.<br>
> >>>><br>
> >>>><br>
> >>>>     Sure, but still, I write more stuff (entire module) into a<br>
> slower destination (file). Even ignoring git execution time it's<br>
> counter intuitive.<br>
> >>>><br>
> >>>>     The only difference is that while I write more, it overwrite<br>
> itself continuously, instead of being a long linear steam. I was<br>
> thinking of mmap the file instead of going through our raw_stream, but<br>
> maybe that's unnecessary then...<br>
> >>>><br>
> >>>><br>
> >>>><br>
> >>>> _______________________________________________<br>
> >>>>     LLVM Developers mailing list<br>
> >>>>     <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> >>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> >>><br>
> >>>     _______________________________________________<br>
> >>>     LLVM Developers mailing list<br>
> >>>     <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> >>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >> --<br>
> >> Alexandre Isoard<br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > LLVM Developers mailing list<br>
> > <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><b>Alexandre Isoard</b><br></div></div>