similar to: New Pass Manager with flto[=thin] not enabled (??)

On Tue, Oct 3, 2017 at 12:08 PM, Davide Italiano <davide at freebsd.org> wrote: > On Tue, Oct 3, 2017 at 11:57 AM, Graham Yiu via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hello, >> >> I recently noticed that the new pass manager was not enabled at regular/thin >> LTO link step even if '-fexperimental-new-pass-manager' was specified in the

Forgot to add that all experiments were done with '-O3 -m64 -fexperimental-new-pass-manager'. Graham Yiu LLVM Compiler Development IBM Toronto Software Lab Office: (905) 413-4077 C2-707/8200/Markham Email: gyiu at ca.ibm.com From: Graham Yiu/Toronto/IBM To: llvm-dev at lists.llvm.org Cc: junbuml at codeaurora.org, xinliangli at gmail.com Date: 11/02/2017 05:26 PM Subject: [RFC]

Hi: &nbsp; &nbsp; I want to learn&nbsp; how LTO and thinLTO work? But I'm confused how lld invoked either library. How can I find it in lld. Should i be familiar with lld source code? And i also think if there is some easy test case and with step-by- step debugging or some log messages can help me learn this? Is there some method can do stuff like this? &nbsp; Thank you very

Hi Graham, Thank you for offering help. I am trying to create a reproducer. The problem is that the crashes happen whilst LTO is used. One thing I am sure about IR is broken at compile time. Thanks, Evgeny From: Graham Yiu <gyiu at ca.ibm.com> Date: Friday, 10 November 2017 at 16:09 To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com> Cc: "junbuml at codeaurora.org"

Hi Teresa, Thanks for the detailed reply! > How are you creating your bitcode files? I create the bitcode with `-flto=thin -c` and sure it has a GLOBALVAL_SUMMARY_BLOCK. And there’s no RegularLTO partition only ThinLTO bicode. > Where is it aborting in the backend? It aborts at ` report_fatal_error("Failed to setup codegen")` in of codegen() of LTOBackend.cpp. And before that in

Hi Evgeny, I just realized that if these are compile-time errors I can help investigate on my end. Do you have something I can use to reproduce? Cheers, Graham Yiu LLVM Compiler Development IBM Toronto Software Lab Office: (905) 413-4077 C2-707/8200/Markham Email: gyiu at ca.ibm.com From: Graham Yiu/Toronto/IBM To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com> Cc:

Greetings everyone! The new pass manager is getting extremely close to the point where I'm not aware of any significant outstanding work needed, and I'd like to see what else would be needed to enable it by default. Here are the current functionality I'm aware of outstanding: 1) Does not do non-trivial loop unswitching. Majority of this is in https://reviews.llvm.org/D34200 but will

Chandler et al, I have been playing with the new PM pipeline, being particularly interested in how it can handle devirtualization. Now, I discovered what I believe is a "regression" vs old PM on a rather simple one-translation-unit testcase. clang is able to devirtualize it with -O3 and fails to do so with -fexperimental-new-pass-manager added. It looks like a pipeline issue,

On 10/25/2017 12:32 PM, Evgeny Astigeevich wrote: > > Hi Hal, > > I quickly checked the execution profile. It is real. The code changed > significantly. A number of the hottest regions changed. I’ll compare IRs. > Thanks. Obviously a 1000% execution performance regression seems problematic. -Hal > JFYI FreeBench/fourinarow time graph: >

On 10/25/2017 12:10 PM, Evgeny Astigeevich via llvm-dev wrote: > > Hi Chandler, > > I ran the LNT benchmarks and SPEC2k6.train on AArch64 Cortex-A57. I > used revisions: Clang 316561, LLVM 316563. > > Options: -O3 -mcpu=cortex-a57 -fomit-frame-pointer > -fexperimental-new-pass-manager > > Regressions: execution time increase > > LNT > >

Sorry, by debug build I actually meant asserts enabled.  Thus, this issue can show up in either a debug or release build, if asserts are enabled. On 10/26/2017 4:05 PM, Chad Rosier via llvm-dev wrote: > > Chandler/All, > > We've just started testing the new pass manager this week and we ran > into a 548x slowdown (i.e., 6.28s to 3443.83s) for one of the files > from

Yes, this looks broken in the new PM. The DevirtSCCRepeatedPass::run method first scans the functions in the SCC to collect value handles for indirect calls, runs the CGSCC pass pipeline and then checks if any of the call value handles now point to a direct call, in which case it runs the pipeline again (which should inline the devirtualized call) . The problem is scanning the initial SCC for

On 10/25/2017 12:16 PM, Xinliang David Li via llvm-dev wrote: > > > On Tue, Oct 17, 2017 at 11:50 PM, Chandler Carruth via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Greetings everyone! > > The new pass manager is getting extremely close to the point where > I'm not aware of any significant

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: > >

Hi Philip, Thank you for your reply. So what would be the right way/API to write out-of-tree pass? I've been using *PassManagerBuilder*, which requires a callback refering to *legacy::PassManagerBase*, so I guess this will be no longer the good way to go? Son Tuan Vu On Tue, Apr 17, 2018 at 6:06 PM, Philip Pfaffe <philip.pfaffe at gmail.com> wrote: > Hi Son, > > I have an

Hello all, I have 2 separate questions: 1, What are the differences between *LegacyPassManager* and *PassManager*? I see that *opt* uses the former most of the times while the latter is used via *PassBuilder* API when an user wants to build her own pipeline, but I have no idea why so. What to use and when to use it is not clear to me. 2, I've asked this question once but have had no answer,

Hello all, Is there a way to register callback that runs before/after passes? PassTimingInfo seems to do a similar thing by calling PassInstrumentationCallbacks::registerBeforePassCallback / registerAfterPassCallback, but it is hard-wired with StandardInstrumentations class. Do we have something similar to RegisterStandardPasses, so custom callbacks can be added from somewhere outside LLVM?

Hello David! I have recently started acquaintance with PGO in LLVM/clang and found your e-mail thread: http://lists.llvm.org/pipermail/llvm-dev/2016-May/099395.html . Here you posted a nice list of optimizations that use profiling and of those which could be using but don't. However that thread is about 2 years old. Could you please kindly let me know if there were any significant changes in

Hi Son, I have an answer to your first question: 1, What are the differences between *LegacyPassManager* and *PassManager*? > I see that *opt* uses the former most of the times while the latter is > used via *PassBuilder* API when an user wants to build her own pipeline, > but I have no idea why so. What to use and when to use it is not clear to > me. > PassManager is the result

Hi Graham, I created a bug report with a reproducer for the failures I’ve got: https://bugs.llvm.org/show_bug.cgi?id=35288 I have also found that LTO reverts everything the partial inliner has done. Maybe the partial inliner should not be used at the first LTO phase (compilation). I hope I’ll have a chance to look at the code size regressions this week. Thanks, Evgeny Astigeevich From: