Fedor Sergeev via llvm-dev
2019-Aug-06 16:35 UTC
[llvm-dev] Status of the New Pass Manager
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.) Does >> anyone else see this? >> >> Are we talking about the same thing? > Apparently both yes and no. > How do you run this? > > IR printing is implemented through pass instrumentation and is enabled > in e.g. opt through the use of StandardInstrumentation > in llvm::runPassPipeline. > If you set up NewPM by yourself w/o the use llvm::runPassPipeline then > most likely you just do not have StandardInstrumentation installed.Reread your mail/output once more and honestly, I do not understand what happens there. Can you share exact setup where you get this? regards, Fedor.> > regards, > Fedor. >> >> *** IR Dump After ObjC ARC contraction *** >> *** IR Dump After Pre-ISel Intrinsic Lowering *** >> *** IR Dump After Expand Atomic instructions *** >> *** IR Dump After Canonicalize natural loops *** >> *** IR Dump After Loop Strength Reduction *** >> *** IR Dump After Merge contiguous icmps into a memcmp *** >> *** IR Dump After Expand memcmp() to load/stores *** >> *** IR Dump After Lower Garbage Collection Instructions *** >> *** IR Dump After Shadow Stack GC Lowering *** >> *** IR Dump After Remove unreachable blocks from the CFG *** >> *** IR Dump After Constant Hoisting *** >> *** IR Dump After Partially inline calls to library functions *** >> *** IR Dump After Instrument function entry/exit with calls to e.g. >> mcount() (post inlining) *** >> *** IR Dump After Scalarize Masked Memory Intrinsics *** >> *** IR Dump After Expand reduction intrinsics *** >> *** IR Dump After Interleaved Access Pass *** >> *** IR Dump After Expand indirectbr instructions *** >> *** IR Dump After CodeGen Prepare *** >> *** IR Dump After Rewrite Symbols *** >> *** IR Dump After Exception handling preparation *** >> *** IR Dump After Safe Stack instrumentation pass *** >> ..... >> (dump from the machine passes) >> >> >> On Sun, Jul 21, 2019 at 7:37 AM Fedor Sergeev >> <fedor.v.sergeev at gmail.com <mailto:fedor.v.sergeev at gmail.com>> wrote: >> >> FWIW, print-*-all should work under NPM just fine and the only >> problem with print-* is (absent) uniform pass name processing for >> cl::opt. >> It is easy to introduce yet another option that takes NPM pass >> names (and that's what we actually did downstream). >> Any suggestions on how to resolve this nuisance are welcome. >> >> regards, >> Fedor. >> >> >> чт, 11 июл. 2019 г., 18:53 Hiroshi Yamauchi via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>: >> >> I don't exactly remember when I last tried it and I didn't >> realize >> there was r342896. I'll check it out. Thanks. >> >> On Wed, Jul 10, 2019 at 1:14 PM Philip Pfaffe >> <philip.pfaffe at gmail.com <mailto:philip.pfaffe at gmail.com>> wrote: >> > >> > Printing was implemented in r342896. >> > @Hiroshi: Are there specific issues or limitations you >> encountered with it? >> > >> > Cheers, >> > Philip >> > >> > On Wed, Jul 10, 2019 at 8:48 PM Troy Johnson via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> >> -print-after-all is very useful for debugging and learning >> about LLVM. I would hope that would be implemented for the >> new PM before removing the old PM. I'd personally consider it >> a blocker. >> >> >> >> -Troy >> >> >> >> > -----Original Message----- >> >> > From: llvm-dev <llvm-dev-bounces at lists.llvm.org >> <mailto:llvm-dev-bounces at lists.llvm.org>> On Behalf Of Eric >> Christopher >> >> > via llvm-dev >> >> > Sent: Tuesday, July 09, 2019 7:40 PM >> >> > To: Hiroshi Yamauchi <yamauchi at google.com >> <mailto:yamauchi at google.com>> >> >> > Cc: llvm-dev <llvm-dev at lists.llvm.org >> <mailto:llvm-dev at lists.llvm.org>>; Yi Kong <yikong at google.com >> <mailto:yikong at google.com>> >> >> > Subject: Re: [llvm-dev] Status of the New Pass Manager >> >> > >> >> > They don't, but this isn't considered a blocker to >> removing the old one as far as I >> >> > know. >> >> > >> >> > -eric >> >> > >> >> > On Tue, Jul 9, 2019 at 11:09 AM Hiroshi Yamauchi via >> llvm-dev <llvm- >> >> > dev at lists.llvm.org <mailto:dev at lists.llvm.org>> wrote: >> >> > > >> >> > > FWIW, the flags like -print-after, -printer-after-all >> don't work well >> >> > > with the new pass manager last time I checked. >> >> > > >> >> > > On Mon, Jul 8, 2019 at 12:20 PM Stephen Hines via llvm-dev >> >> > > <llvm-dev at lists.llvm.org >> <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> > > > >> >> > > > The Android platform build (AOSP) has also switched >> to the new pass >> >> > manager recently. We do have a few bugs that we are >> chasing (hence opt-outs), >> >> > but it is working quite well otherwise. >> >> > > > >> >> > > > Our current list of issues: >> >> > > > 1) Libsqlite still has a mysterious failure that we >> haven't been able to reduce >> >> > well. >> >> > > > 2) https://bugs.llvm.org/show_bug.cgi?id=42124 shows >> that inlining costs >> >> > are a bit different under NPM. >> https://reviews.llvm.org/D63034 is one proposed >> >> > patch for addressing this. >> >> > > > 3) libpdfium exposed a non-determinism issue with >> NPM where having the >> >> > linux-libc-dev system package installed changes >> execution. We are still looking >> >> > at why this happens. >> >> > > > 4) Sanitizer coverage information isn't supported by >> the NPM yet >> >> > (https://reviews.llvm.org/D62888). >> >> > > > >> >> > > > Thanks, >> >> > > > Steve >> >> > > > >> >> > > > On Mon, Jul 1, 2019 at 11:07 AM Alex Bradbury via >> llvm-dev <llvm- >> >> > dev at lists.llvm.org <mailto:dev at lists.llvm.org>> wrote: >> >> > > >> >> >> > > >> On Thu, 27 Jun 2019 at 17:46, Philip Reames via >> llvm-dev >> >> > > >> <llvm-dev at lists.llvm.org >> <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> > > >> > >> >> > > >> > For our downstream usage, we've switched entirely >> to the new pass >> >> > manager. We made the switch a couple of months ago. >> All of our testing is >> >> > being done with the NPM, and we're about to start >> deleting (downstream) code >> >> > which was only needed by the legacy pass manager. >> >> > > >> > >> >> > > >> > I believe several other major contributors are in >> the same state. We >> >> > really need to get upstream switched over so that all of >> the community's testing >> >> > efforts are aligned again. >> >> > > >> >> >> > > >> I hadn't realised it was so close to being ready. >> Do you see this >> >> > > >> as a switch that could be made before 9.0, or after it? >> >> > > >> >> >> > > >> Best, >> >> > > >> >> >> > > >> Alex >> >> > > >> _______________________________________________ >> >> > > >> LLVM Developers mailing list >> >> > > >> llvm-dev at lists.llvm.org >> <mailto:llvm-dev at lists.llvm.org> >> >> > > >> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> > > > >> >> > > > _______________________________________________ >> >> > > > LLVM Developers mailing list >> >> > > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> >> > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> > > _______________________________________________ >> >> > > LLVM Developers mailing list >> >> > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> >> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> > _______________________________________________ >> >> > LLVM Developers mailing list >> >> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190806/c1c7e8cf/attachment-0001.html>
Hiroshi Yamauchi via llvm-dev
2019-Aug-07 15:20 UTC
[llvm-dev] Status of the New Pass Manager
I basically run "clang -fexperimental-new-pass-manager -print-after-all ..." It'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. Thanks. On Tue, Aug 6, 2019 at 9:35 AM Fedor Sergeev <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-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.) Does > anyone else see this? > > Are we talking about the same thing? > > Apparently both yes and no. > How do you run this? > > IR printing is implemented through pass instrumentation and is enabled in > e.g. opt through the use of StandardInstrumentation > in llvm::runPassPipeline. > If you set up NewPM by yourself w/o the use llvm::runPassPipeline then > most likely you just do not have StandardInstrumentation installed. > > Reread your mail/output once more and honestly, I do not understand what > happens there. > Can you share exact setup where you get this? > > regards, > Fedor. > > > regards, > Fedor. > > > *** IR Dump After ObjC ARC contraction *** > *** IR Dump After Pre-ISel Intrinsic Lowering *** > *** IR Dump After Expand Atomic instructions *** > *** IR Dump After Canonicalize natural loops *** > *** IR Dump After Loop Strength Reduction *** > *** IR Dump After Merge contiguous icmps into a memcmp *** > *** IR Dump After Expand memcmp() to load/stores *** > *** IR Dump After Lower Garbage Collection Instructions *** > *** IR Dump After Shadow Stack GC Lowering *** > *** IR Dump After Remove unreachable blocks from the CFG *** > *** IR Dump After Constant Hoisting *** > *** IR Dump After Partially inline calls to library functions *** > *** IR Dump After Instrument function entry/exit with calls to e.g. > mcount() (post inlining) *** > *** IR Dump After Scalarize Masked Memory Intrinsics *** > *** IR Dump After Expand reduction intrinsics *** > *** IR Dump After Interleaved Access Pass *** > *** IR Dump After Expand indirectbr instructions *** > *** IR Dump After CodeGen Prepare *** > *** IR Dump After Rewrite Symbols *** > *** IR Dump After Exception handling preparation *** > *** IR Dump After Safe Stack instrumentation pass *** > ..... > (dump from the machine passes) > > > On Sun, Jul 21, 2019 at 7:37 AM Fedor Sergeev <fedor.v.sergeev at gmail.com> > wrote: > >> FWIW, print-*-all should work under NPM just fine and the only problem >> with print-* is (absent) uniform pass name processing for cl::opt. >> It is easy to introduce yet another option that takes NPM pass names (and >> that's what we actually did downstream). >> Any suggestions on how to resolve this nuisance are welcome. >> >> regards, >> Fedor. >> >> >> чт, 11 июл. 2019 г., 18:53 Hiroshi Yamauchi via llvm-dev < >> llvm-dev at lists.llvm.org>: >> >>> I don't exactly remember when I last tried it and I didn't realize >>> there was r342896. I'll check it out. Thanks. >>> >>> On Wed, Jul 10, 2019 at 1:14 PM Philip Pfaffe <philip.pfaffe at gmail.com> >>> wrote: >>> > >>> > Printing was implemented in r342896. >>> > @Hiroshi: Are there specific issues or limitations you encountered >>> with it? >>> > >>> > Cheers, >>> > Philip >>> > >>> > On Wed, Jul 10, 2019 at 8:48 PM Troy Johnson via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >> >>> >> -print-after-all is very useful for debugging and learning about >>> LLVM. I would hope that would be implemented for the new PM before >>> removing the old PM. I'd personally consider it a blocker. >>> >> >>> >> -Troy >>> >> >>> >> > -----Original Message----- >>> >> > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Eric >>> Christopher >>> >> > via llvm-dev >>> >> > Sent: Tuesday, July 09, 2019 7:40 PM >>> >> > To: Hiroshi Yamauchi <yamauchi at google.com> >>> >> > Cc: llvm-dev <llvm-dev at lists.llvm.org>; Yi Kong <yikong at google.com> >>> >> > Subject: Re: [llvm-dev] Status of the New Pass Manager >>> >> > >>> >> > They don't, but this isn't considered a blocker to removing the old >>> one as far as I >>> >> > know. >>> >> > >>> >> > -eric >>> >> > >>> >> > On Tue, Jul 9, 2019 at 11:09 AM Hiroshi Yamauchi via llvm-dev <llvm- >>> >> > dev at lists.llvm.org> wrote: >>> >> > > >>> >> > > FWIW, the flags like -print-after, -printer-after-all don't work >>> well >>> >> > > with the new pass manager last time I checked. >>> >> > > >>> >> > > On Mon, Jul 8, 2019 at 12:20 PM Stephen Hines via llvm-dev >>> >> > > <llvm-dev at lists.llvm.org> wrote: >>> >> > > > >>> >> > > > The Android platform build (AOSP) has also switched to the new >>> pass >>> >> > manager recently. We do have a few bugs that we are chasing (hence >>> opt-outs), >>> >> > but it is working quite well otherwise. >>> >> > > > >>> >> > > > Our current list of issues: >>> >> > > > 1) Libsqlite still has a mysterious failure that we haven't >>> been able to reduce >>> >> > well. >>> >> > > > 2) https://bugs.llvm.org/show_bug.cgi?id=42124 shows that >>> inlining costs >>> >> > are a bit different under NPM. https://reviews.llvm.org/D63034 is >>> one proposed >>> >> > patch for addressing this. >>> >> > > > 3) libpdfium exposed a non-determinism issue with NPM where >>> having the >>> >> > linux-libc-dev system package installed changes execution. We are >>> still looking >>> >> > at why this happens. >>> >> > > > 4) Sanitizer coverage information isn't supported by the NPM yet >>> >> > (https://reviews.llvm.org/D62888). >>> >> > > > >>> >> > > > Thanks, >>> >> > > > Steve >>> >> > > > >>> >> > > > On Mon, Jul 1, 2019 at 11:07 AM Alex Bradbury via llvm-dev >>> <llvm- >>> >> > dev at lists.llvm.org> wrote: >>> >> > > >> >>> >> > > >> On Thu, 27 Jun 2019 at 17:46, Philip Reames via llvm-dev >>> >> > > >> <llvm-dev at lists.llvm.org> wrote: >>> >> > > >> > >>> >> > > >> > For our downstream usage, we've switched entirely to the new >>> pass >>> >> > manager. We made the switch a couple of months ago. All of our >>> testing is >>> >> > being done with the NPM, and we're about to start deleting >>> (downstream) code >>> >> > which was only needed by the legacy pass manager. >>> >> > > >> > >>> >> > > >> > I believe several other major contributors are in the same >>> state. We >>> >> > really need to get upstream switched over so that all of the >>> community's testing >>> >> > efforts are aligned again. >>> >> > > >> >>> >> > > >> I hadn't realised it was so close to being ready. Do you see >>> this >>> >> > > >> as a switch that could be made before 9.0, or after it? >>> >> > > >> >>> >> > > >> Best, >>> >> > > >> >>> >> > > >> Alex >>> >> > > >> _______________________________________________ >>> >> > > >> LLVM Developers mailing list >>> >> > > >> llvm-dev at lists.llvm.org >>> >> > > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> > > > >>> >> > > > _______________________________________________ >>> >> > > > LLVM Developers mailing list >>> >> > > > llvm-dev at lists.llvm.org >>> >> > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> > > _______________________________________________ >>> >> > > LLVM Developers mailing list >>> >> > > llvm-dev at lists.llvm.org >>> >> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> > _______________________________________________ >>> >> > LLVM Developers mailing list >>> >> > llvm-dev at lists.llvm.org >>> >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> _______________________________________________ >>> >> LLVM Developers mailing list >>> >> llvm-dev at lists.llvm.org >>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> > _______________________________________________ > LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > _______________________________________________ > LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190807/58a007ce/attachment.html>
Fedor Sergeev via llvm-dev
2019-Aug-07 15:33 UTC
[llvm-dev] Status of the New Pass Manager
On 8/7/19 6:20 PM, Hiroshi Yamauchi wrote:> I basically run "clang > -fexperimental-new-pass-manager -print-after-all ..." > > It'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-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.) >>> Does anyone else see this? >>> >>> Are we talking about the same thing? >> Apparently both yes and no. >> How do you run this? >> >> IR printing is implemented through pass instrumentation and is >> enabled in e.g. opt through the use of StandardInstrumentation >> in llvm::runPassPipeline. >> If you set up NewPM by yourself w/o the use llvm::runPassPipeline >> then most likely you just do not have StandardInstrumentation >> installed. > Reread your mail/output once more and honestly, I do not > understand what happens there. > Can you share exact setup where you get this? > > regards, > Fedor. > >> >> regards, >> Fedor. >>> >>> *** IR Dump After ObjC ARC contraction *** >>> *** IR Dump After Pre-ISel Intrinsic Lowering *** >>> *** IR Dump After Expand Atomic instructions *** >>> *** IR Dump After Canonicalize natural loops *** >>> *** IR Dump After Loop Strength Reduction *** >>> *** IR Dump After Merge contiguous icmps into a memcmp *** >>> *** IR Dump After Expand memcmp() to load/stores *** >>> *** IR Dump After Lower Garbage Collection Instructions *** >>> *** IR Dump After Shadow Stack GC Lowering *** >>> *** IR Dump After Remove unreachable blocks from the CFG *** >>> *** IR Dump After Constant Hoisting *** >>> *** IR Dump After Partially inline calls to library functions *** >>> *** IR Dump After Instrument function entry/exit with calls to >>> e.g. mcount() (post inlining) *** >>> *** IR Dump After Scalarize Masked Memory Intrinsics *** >>> *** IR Dump After Expand reduction intrinsics *** >>> *** IR Dump After Interleaved Access Pass *** >>> *** IR Dump After Expand indirectbr instructions *** >>> *** IR Dump After CodeGen Prepare *** >>> *** IR Dump After Rewrite Symbols *** >>> *** IR Dump After Exception handling preparation *** >>> *** IR Dump After Safe Stack instrumentation pass *** >>> ..... >>> (dump from the machine passes) >>> >>> >>> On Sun, Jul 21, 2019 at 7:37 AM Fedor Sergeev >>> <fedor.v.sergeev at gmail.com <mailto:fedor.v.sergeev at gmail.com>> >>> wrote: >>> >>> FWIW, print-*-all should work under NPM just fine and the >>> only problem with print-* is (absent) uniform pass name >>> processing for cl::opt. >>> It is easy to introduce yet another option that takes NPM >>> pass names (and that's what we actually did downstream). >>> Any suggestions on how to resolve this nuisance are welcome. >>> >>> regards, >>> Fedor. >>> >>> >>> чт, 11 июл. 2019 г., 18:53 Hiroshi Yamauchi via llvm-dev >>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>: >>> >>> I don't exactly remember when I last tried it and I >>> didn't realize >>> there was r342896. I'll check it out. Thanks. >>> >>> On Wed, Jul 10, 2019 at 1:14 PM Philip Pfaffe >>> <philip.pfaffe at gmail.com >>> <mailto:philip.pfaffe at gmail.com>> wrote: >>> > >>> > Printing was implemented in r342896. >>> > @Hiroshi: Are there specific issues or limitations you >>> encountered with it? >>> > >>> > Cheers, >>> > Philip >>> > >>> > On Wed, Jul 10, 2019 at 8:48 PM Troy Johnson via >>> llvm-dev <llvm-dev at lists.llvm.org >>> <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >> >>> >> -print-after-all is very useful for debugging and >>> learning about LLVM. I would hope that would be >>> implemented for the new PM before removing the old PM. >>> I'd personally consider it a blocker. >>> >> >>> >> -Troy >>> >> >>> >> > -----Original Message----- >>> >> > From: llvm-dev <llvm-dev-bounces at lists.llvm.org >>> <mailto:llvm-dev-bounces at lists.llvm.org>> On Behalf Of >>> Eric Christopher >>> >> > via llvm-dev >>> >> > Sent: Tuesday, July 09, 2019 7:40 PM >>> >> > To: Hiroshi Yamauchi <yamauchi at google.com >>> <mailto:yamauchi at google.com>> >>> >> > Cc: llvm-dev <llvm-dev at lists.llvm.org >>> <mailto:llvm-dev at lists.llvm.org>>; Yi Kong >>> <yikong at google.com <mailto:yikong at google.com>> >>> >> > Subject: Re: [llvm-dev] Status of the New Pass Manager >>> >> > >>> >> > They don't, but this isn't considered a blocker to >>> removing the old one as far as I >>> >> > know. >>> >> > >>> >> > -eric >>> >> > >>> >> > On Tue, Jul 9, 2019 at 11:09 AM Hiroshi Yamauchi >>> via llvm-dev <llvm- >>> >> > dev at lists.llvm.org <mailto:dev at lists.llvm.org>> wrote: >>> >> > > >>> >> > > FWIW, the flags like -print-after, >>> -printer-after-all don't work well >>> >> > > with the new pass manager last time I checked. >>> >> > > >>> >> > > On Mon, Jul 8, 2019 at 12:20 PM Stephen Hines via >>> llvm-dev >>> >> > > <llvm-dev at lists.llvm.org >>> <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >> > > > >>> >> > > > The Android platform build (AOSP) has also >>> switched to the new pass >>> >> > manager recently. We do have a few bugs that we are >>> chasing (hence opt-outs), >>> >> > but it is working quite well otherwise. >>> >> > > > >>> >> > > > Our current list of issues: >>> >> > > > 1) Libsqlite still has a mysterious failure >>> that we haven't been able to reduce >>> >> > well. >>> >> > > > 2) https://bugs.llvm.org/show_bug.cgi?id=42124 >>> shows that inlining costs >>> >> > are a bit different under NPM. >>> https://reviews.llvm.org/D63034 is one proposed >>> >> > patch for addressing this. >>> >> > > > 3) libpdfium exposed a non-determinism issue >>> with NPM where having the >>> >> > linux-libc-dev system package installed changes >>> execution. We are still looking >>> >> > at why this happens. >>> >> > > > 4) Sanitizer coverage information isn't >>> supported by the NPM yet >>> >> > (https://reviews.llvm.org/D62888). >>> >> > > > >>> >> > > > Thanks, >>> >> > > > Steve >>> >> > > > >>> >> > > > On Mon, Jul 1, 2019 at 11:07 AM Alex Bradbury >>> via llvm-dev <llvm- >>> >> > dev at lists.llvm.org <mailto:dev at lists.llvm.org>> wrote: >>> >> > > >> >>> >> > > >> On Thu, 27 Jun 2019 at 17:46, Philip Reames >>> via llvm-dev >>> >> > > >> <llvm-dev at lists.llvm.org >>> <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >> > > >> > >>> >> > > >> > For our downstream usage, we've switched >>> entirely to the new pass >>> >> > manager. We made the switch a couple of months >>> ago. All of our testing is >>> >> > being done with the NPM, and we're about to start >>> deleting (downstream) code >>> >> > which was only needed by the legacy pass manager. >>> >> > > >> > >>> >> > > >> > I believe several other major contributors >>> are in the same state. We >>> >> > really need to get upstream switched over so that >>> all of the community's testing >>> >> > efforts are aligned again. >>> >> > > >> >>> >> > > >> I hadn't realised it was so close to being >>> ready. Do you see this >>> >> > > >> as a switch that could be made before 9.0, or >>> after it? >>> >> > > >> >>> >> > > >> Best, >>> >> > > >> >>> >> > > >> Alex >>> >> > > >> _______________________________________________ >>> >> > > >> LLVM Developers mailing list >>> >> > > >> llvm-dev at lists.llvm.org >>> <mailto:llvm-dev at lists.llvm.org> >>> >> > > >> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> > > > >>> >> > > > _______________________________________________ >>> >> > > > LLVM Developers mailing list >>> >> > > > llvm-dev at lists.llvm.org >>> <mailto:llvm-dev at lists.llvm.org> >>> >> > > > >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> > > _______________________________________________ >>> >> > > LLVM Developers mailing list >>> >> > > llvm-dev at lists.llvm.org >>> <mailto:llvm-dev at lists.llvm.org> >>> >> > > >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> > _______________________________________________ >>> >> > LLVM Developers mailing list >>> >> > llvm-dev at lists.llvm.org >>> <mailto:llvm-dev at lists.llvm.org> >>> >> > >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> _______________________________________________ >>> >> LLVM Developers mailing list >>> >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190807/01ecb6bb/attachment-0001.html>
Apparently Analagous Threads
- Status of the New Pass Manager
- Status of the New Pass Manager
- Status of the New Pass Manager
- RFC: Getting ProfileSummaryInfo and BlockFrequencyInfo from various types of passes under the new pass manager
- RFC: Getting ProfileSummaryInfo and BlockFrequencyInfo from various types of passes under the new pass manager