Hiroshi Yamauchi via llvm-dev
2019-Aug-06 00:02 UTC
[llvm-dev] Status of the New Pass Manager
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? *** 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 >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190805/eba68068/attachment.html>
Fedor Sergeev via llvm-dev
2019-Aug-06 16:31 UTC
[llvm-dev] Status of the New Pass Manager
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. 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-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190806/d496b67a/attachment.html>
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>