search for: sergeev

...s mmapped into memory continuously, while piping require regular (more than once per module) context switches between the 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. > >...

The print-module-after-all type of option exists in upstream: -print-module-scope - When printing IR for print-[before|after]{-all} always print a module IR commit 7d160f714357f6784ead669ce516e94991c12e5a Author: Fedor Sergeev <fedor.sergeev at azul.com<mailto:fedor.sergeev at azul.com>> Date: Fri Dec 1 17:42:46 2017 +0000 IR printing improvement for function passes - introducing -print-module-scope Summary: When debugging function passes it happens to be rather useful to dump the whole...

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

...st paragraph). I > didn't build that with efficiency in mind in any way... Well, git by itself is so focused on performance, so its not surprising to me that even using git 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 waaaa...

...-commit-after-all 2>/dev/null real    0m8.041s user    0m7.133s sys     0m0.936s ] time R/bin/opt -O3 some-ir.ll -disable-output -print-after-all 2>/dev/null real    0m13.575s user    0m6.179s sys     0m7.394s I cant really explain that... regards,   Fedor. On 03/15/2018 04:30 PM, Fedor Sergeev via llvm-dev wrote: > > > 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...

...-dev wrote: > The print-module-after-all type of option exists in upstream: >   -print-module-scope                                     - When > printing IR for print-[before|after]{-all} always print a module IR > > commit 7d160f714357f6784ead669ce516e94991c12e5a > Author: Fedor Sergeev <fedor.sergeev at azul.com > <mailto:fedor.sergeev at azul.com>> > Date:   Fri Dec 1 17:42:46 2017 +0000 > >     IR printing improvement for function passes - introducing > -print-module-scope > > >     Summary: >     When debugging function passes it happen...

Is there a reason for why `-asan` and `-asan-module` can be mixed but Function passes and Module passes with the new PM can't be mixed? - Leo On Thu, Sep 27, 2018 at 3:21 AM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > > On 09/27/2018 12:25 PM, Philip Pfaffe wrote: >> >> `opt < %s -passed='asan' -asan-module -S` > > asan-module is another ModulePass, not a commandline option. You can't mix that like this. > > I'm inclined...

...e my poor excuse from earlier (else we should map all pipes into files!), but I'm curious why we spend less time in system mode when going through file than pipe. Maybe /dev/null is not as efficient as we might think? I can't believe I'm saying that... On Thu, Mar 15, 2018, 08:25 Fedor Sergeev <fedor.sergeev at azul.com> wrote: > Well, git by itself is so focused on performance, so its not surprising > to me that even using git add/git commit does not cause > performance penalties. > Sure, but still, I write more stuff (entire module) into a slower destination (file)....

Hello Fedor. Thank you for the information. I made a simple patch that exposes PassInstrumentationCallback so llvmGetPassPluginInfo can use it: https://reviews.llvm.org/D71086 . Would this change make sense? Thanks, Juneyoung Lee On Thu, Dec 12, 2019 at 12:44 AM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > > > On 12/3/19 8:01 PM, Juneyoung Lee via llvm-dev wrote: > > Hello all, > > Is there a way to register callback that runs before/after passes? > PassTimingInfo seems to do a similar thing by calling > PassInstrumentationCallbac...

On 3/14/19 2:04 AM, Hiroshi Yamauchi wrote: > > > On Wed, Mar 13, 2019 at 2:37 PM Fedor Sergeev <fedor.sergeev at azul.com > <mailto:fedor.sergeev at azul.com>> wrote: > >> >> - Add a new proxy ModuleAnalysisManagerLoopProxy for a loop pass >> to be able to get to the ModuleAnalysisManager in one step and >> PSI through it. > This...

On 06/13/2018 09:13 PM, Philip Pfaffe wrote: > On Wed, Jun 13, 2018 at 8:03 PM David A. Greene via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Fedor Sergeev <fedor.sergeev at azul.com > <mailto:fedor.sergeev at azul.com>> writes: > > >> Ok.  The way I envision this working from a user standpoint is > >> -opt-bisect-limit <n> would mean "n applications of code > >> transformation.&q...

...er (else we should map all > pipes into files!), but I'm curious why we spend less time in system > mode when going through file than pipe. Maybe /dev/null is not as > efficient as we might think? I can't believe I'm saying that... > > On Thu, Mar 15, 2018, 08:25 Fedor Sergeev <fedor.sergeev at azul.com > <mailto:fedor.sergeev at azul.com>> wrote: > > Well, git by itself is so focused on performance, so its not > surprising > to me that even using git add/git commit does not cause > performance penalties. > > > Sure...

...PSI through it. This is just an optimization of compile-time, saves one indirection through FunctionAnalysisManager. I'm not even sure if it is worth the effort. And definitely not crucial for the overall idea. regards,   Fedor. > > > > > On Mon, Mar 4, 2019 at 2:05 PM Fedor Sergeev <fedor.sergeev at azul.com > <mailto:fedor.sergeev at azul.com>> wrote: > > > > On 3/4/19 10:49 PM, Hiroshi Yamauchi wrote: >> >> >> On Mon, Mar 4, 2019 at 10:55 AM Hiroshi Yamauchi >> <yamauchi at google.com <mailto:yamauchi at...

...#39;m curious why we spend less time >>> in system mode when going through file than pipe. Maybe >>> /dev/null is not as efficient as we might think? I can't believe >>> I'm saying that... >>> >>> On Thu, Mar 15, 2018, 08:25 Fedor Sergeev >>> <fedor.sergeev at azul.com <mailto:fedor.sergeev at azul.com>> wrote: >>> >>> Well, git by itself is so focused on performance, so its not >>> surprising >>> to me that even using git add/git commit does not ca...

...t's conceivable that something is different in our setup or in clang > (from opt)... I'll see if I can reproduce it outside our setup. Does it depend on machine architecture? I generally use x86... regards,   Fedor. > > Thanks. > > > On Tue, Aug 6, 2019 at 9:35 AM Fedor Sergeev <fedor.sergeev at azul.com > <mailto:fedor.sergeev at azul.com>> wrote: > > > > On 8/6/19 7:31 PM, Fedor Sergeev via llvm-dev wrote: >> >> >> On 8/6/19 3:02 AM, Hiroshi Yamauchi via llvm-dev wrote: >>> I had a chance to try -print-a...

Frontends _are_ using PassBuilder, but they need to hook into the default pipeline creation to insert the sanitizer passes. On Tue, Sep 25, 2018 at 12:15 PM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > Hmm... frontends should be using PassBuilder anyway. > And if they are using PassBuilder then they are using PassRegistry.def as > well - all the > PassBuilder::register*/parse*/is* methods do include PassRegistry.def in > their bodies. &gt...

On 8/6/19 7:31 PM, Fedor Sergeev via llvm-dev wrote: > > > On 8/6/19 3:02 AM, Hiroshi Yamauchi via llvm-dev wrote: >> I had a chance to try -print-after-all with NPM. >> >> It seems like there's still no output for the passes >> before objc-arc-contract (which is basically what I saw before.)...

...s user    0m2.373s sys     0m0.271s ] So, the morale of this story is - we should not be printing module IR into dbgs/errs(). And then the idea of streaming IR module dumps into a buffered stream and then postprocessing seems to be a right one. regards,   Fedor. On 03/21/2018 01:08 PM, Fedor Sergeev via llvm-dev wrote: > On 03/16/2018 01:21 AM, Fedor Sergeev via llvm-dev wrote: > > git-commit-after-all solution has one serious issue - it has a > hardcoded git handling which > > makes it look problematic from many angles (picking a proper git, > > selecting exact way of...

...rom earlier (else we should map all pipes into files!), but I'm curious why we spend less time in system mode when going through file than pipe. Maybe /dev/null is not as efficient as we might think? I can't believe I'm saying that... >> >> On Thu, Mar 15, 2018, 08:25 Fedor Sergeev <fedor.sergeev at azul.com <mailto:fedor.sergeev at azul.com>> wrote: >> Well, git by itself is so focused on performance, so its not surprising >> to me that even using git add/git commit does not cause >> performance penalties. >> >> Sure, but still, I w...

...stream::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. > > > On Thu, Mar 22, 2018 at 8:06 AM Fedor Sergeev via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Oh, well... as usually the answer appears to be pretty obvious. >> 99% of the time is spent inside the plain write. >> >> -print-after-all prints into llvm::errs(), which is an *unbuffered* >> raw_fd_...