[llvm-dev] Status of the New Pass Manager

Hiroshi Yamauchi via llvm-dev llvm-dev at lists.llvm.org
Wed Aug 7 15:16:07 PDT 2019


On Wed, Aug 7, 2019 at 8:33 AM Fedor Sergeev <fedor.sergeev at azul.com> wrote:

>
>
> On 8/7/19 6:20 PM, Hiroshi Yamauchi wrote:
>
> I basically run "clang -fexperimental-new-pass-manager -print-after-all
> ..."
>
> It actually needs "-mllvm" in front of "-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...
>

I'm not sure, but this is on x86.


> regards,
>   Fedor.
>
>
> 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/7cc3df54/attachment.html>


More information about the llvm-dev mailing list