[llvm-dev] Status of the New Pass Manager
Fedor Sergeev via llvm-dev
llvm-dev at lists.llvm.org
Wed Aug 7 08:33:11 PDT 2019
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>
More information about the llvm-dev
mailing list