search for: d44244

Maybe. I can't compute the diff/patch for git though, it will have to do it itself. Would that still work? I am not sure I will have time to work on improving that. For those who want to try it out I put it there: https://reviews.llvm.org/D44244 And yes, this uses all possible forms of ugly. :-) On Wed, Mar 7, 2018, 18:14 Jeremy Lakeman <Jeremy.Lakeman at gmail.com> wrote: > Could you format the output so that it is compatible with git fast-import? > https://www.git-scm.com/docs/git-fast-import > > On Thu, Mar 8, 2018...

Hmm... I tried Alexandre's fix from D44244 and surprisingly it appears that just using -print-module-scope w/o any additional git actions is waaaay slower on my testcase than -git-commit-module-all. Hell, even a plan -print-after-all is slower:  ] time R/bin/opt -O3 some-ir.ll -disable-output -git-commit-after-all 2>/dev/null real ...

...e two processes? Honestly, I would say something is wrong (aka. first paragraph). I didn't build that with efficiency in mind in any way... On Thu, Mar 15, 2018, 07:47 Fedor Sergeev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hmm... > > I tried Alexandre's fix from D44244 and surprisingly it appears that > just using -print-module-scope w/o > any additional git actions is waaaay slower on my testcase than > -git-commit-module-all. > > Hell, even a plan -print-after-all is slower: > > ] time R/bin/opt -O3 some-ir.ll -disable-output -git-commit-...

On 03/15/2018 01:32 PM, Fedor Sergeev via llvm-dev wrote: > For this to be really usable in this setup we need additionally to: >   - extend -print-module-scope to cover basic block passes >   - introduce a clear way to separate module IRs as those are being > printed by -print-after-all > > But yes, it should work, and a wrapper that pipes to git fast-import > seems to be

Could you format the output so that it is compatible with git fast-import? https://www.git-scm.com/docs/git-fast-import On Thu, Mar 8, 2018 at 2:34 AM, Alexandre Isoard via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Today it is entirely in llvm. It is even more costly than -print-after-all > as it: > - print to file > - print the entire module (after each basic block,

This is interesting, and might be useful.  I don't know that this is broadly useful enough for upstream inclusion, but if you could post this to github somewhere, I might play with it. There might also be room to factor out common functionality. We've also run into the need to print whole-module instead of containing construct (i.e. this loop).  If we added upstream support for

...it add/git commit does not cause performance penalties. regards,   Fedor. > > On Thu, Mar 15, 2018, 07:47 Fedor Sergeev via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Hmm... > > I tried Alexandre's fix from D44244 and surprisingly it appears that > just using -print-module-scope w/o > any additional git actions is waaaay slower on my testcase than > -git-commit-module-all. > > Hell, even a plan -print-after-all is slower: > >   ] time R/bin/opt -O3 some-ir.ll -disable...

Today it is entirely in llvm. It is even more costly than -print-after-all as it: - print to file - print the entire module (after each basic block, for basic block passes, it will still print the entire module where only one basic block changed) - call git 2 times (add then commit) and wait for them to finish (I even save all the empty commits) The reason I print the entire module is so

Hello, I had a stupid idea recently that turned out not so stupid after all. I wanted to be able to "see" an entire pass pipeline in action to find unnecessary transformations and/or missed opportunities and generally improve the debug-ability of LLVM. So as the title suggest, I implemented an equivalent of "-print-after-all" but instead of printing into stdout I dump into a