similar to: [NPM] Register target specific pass with opt

-Yuanfang > -----Original Message----- > From: Arthur Eubanks <aeubanks at google.com> > Sent: Monday, July 13, 2020 12:49 PM > To: Chen, Yuanfang <Yuanfang.Chen at sony.com> > Cc: LLVM Developers' List <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen driven by > new pass manager > > While we're

> On Jul 15, 2020, at 12:28, Chen, Yuanfang <Yuanfang.Chen at sony.com> wrote: > > In codegen with NPM, I've made all codegen passes (IR or MIR pass) to be only driven by `llc`. Both due to the way NPM registering pass (on-demand&dynamic instead of static initialization in Legacy PM), and reduce the confusion about which tool (`llc` or `opt`) to test codegen IR passes. >

On Thu, Jun 25, 2020 at 9:59 AM Roman Lebedev <lebedev.ri at gmail.com> wrote: > On Thu, Jun 25, 2020 at 7:48 PM Arthur Eubanks via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > After talking with some NPM people, I believe the ultimate goal after > NPM is enabled by default is to only support `-passes=`, and remove support > for `-foo-pass`. > Hm,

On Wed, Jul 15, 2020 at 6:39 PM Chen, Yuanfang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Indeed, but there is a distinction about their position in the pipeline. We run opt & codegen pipeline separately, Why, though? Is there a reason why this inherently makes sense, or is it just a historical accident? At least to me it seems that it would make more sense to run all passes

> On Jul 15, 2020, at 09:16, Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> I'd just note that not every pass you can run with "opt" is actually part of the optimization pipeline. There are a few important IR-level passes that only run in the codegen pipeline, but are still nameable with opt to run individually for testing purposes. Switching

One thing I want to mention. I believe in the current legacy pass manager implementation only one MachineFunction ever exists at a time. It is deleted before the next MachineFunction is created. This is very important for memory usage. I think the MachineOutliner being in the pipeline may create an exception to this. I think the initial version of retpoline used a ModulePass and that had to be

(NPM: new pass manager; LPM: legacy pass manager) Hello, community While we're still working towards using NPM for optimizer pipeline by default, we still don't have a machine pass interface and the corresponding machine pass manager using NPM. The potential benefits using NPM aside, this inhibits us from making any progress on deprecating LPM for the codegen pipeline which blocks

(NPM: new pass manager; LPM: legacy pass manager) In a first quick experiment today I compared code-size of the LMP vs. the NMP for the CSiBE benchmark (and some other), and this shows code-size increases with the NPM that would probably be unacceptable for us. So, now I am wondering how/if we need to mitigate this, and have a bunch of questions. As I've noticed quite some activity around

Hi all, I wanted to give a quick update on the status of NPM for the IR optimization pipeline and ask some questions. In the past I believe there were thoughts that NPM was basically ready because all of check-llvm and check-clang passed when -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=ON was specified. But that CMake flag did not apply to opt and any tests running something like `opt -foo-pass

Looking through some of the remaining test failures under the new pass manager, I've narrowed down one of the failures in GWPAsan(!) to the fact that the new pass manager doesn't properly skip passes like the old pass manager. For example, when a function is marked optnone, or when using https://llvm.org/docs/OptBisect.html. Lots of passes (e.g. SROA) will do the following under the

I'd just note that not every pass you can run with "opt" is actually part of the optimization pipeline. There are a few important IR-level passes that only run in the codegen pipeline, but are still nameable with opt to run individually for testing purposes. Switching over doesn't need to block on these passes being migrated. So I'm not sure this method of determining

Hi, I have built successfully all the dependent packages of nodejs010 and npm. I have used following command:- *rpmbuild --define 'scl nodejs010' --bb SPEC/name_of_spec.spec* Following is the list of RPMs cloned and built from GIT:- nodejs010-2.1-5.el7.centos.x86_64.rpm nodejs010-http-parser-2.0-6.20121128gitcd01361.el7.centos.x86_64.rpm

Dear ALL Please tell me how to configure Openldap in rhel 5 Please send me links & document Thanks in advance Ankit Jariwala 9725655020

Hi, I have built dependent packages of nodejs010 and npm successfully using mock and copy these RPMS to our ISO, anaconada installer fails to install due to dependency errors: nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.noarch requires nodejs010-npm(readable-stream) < 2 nodejs010-nodejs-cmd-shim-2.0.0-2.el7.centos.noarch requires nodejs010-npm(graceful-fs) < 4

Hi All, I changed the CFG of a big function using a pass that runs on a function, I am having trouble debugging it. Is there someway to dump a module to a file from inside gdb? I have access to the Module pointer. Let me know if anything else is needed. -- *Ankit* -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, I'm interested in the sort of pass where you write `-passes=print<pass-name>` and it calls the `print()` function of the pass. I have seen some other passes that can invoke `-passes=print<>` but the implementation seems to be in the wrapper pass for the old pass manager. Thanks, Stefanos Baziotis -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi All, I am using llvm-2.9 to cross compile to alpha. I know that alpha is in experimental stage, but i can not get even the "Hello World" program to run on it. Here is what happens, the bitcode file for the hello world program is as follow: ; ModuleID = 'hello.bc' target datalayout =

Ankit, >From within GDB you can run the following command: "call m->dump()" This will print the module in the bitcode in a textual format. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Ankit Sethia Sent: Saturday, June 25, 2011 20:56 To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] dump a module from inside GDB to a file Hi All, I

Hi Matt, which analysis is this? ________________________________________ From: Matt Arsenault <whatmannerofburgeristhis at gmail.com> on behalf of Matt Arsenault <arsenm2 at gmail.com> Sent: Tuesday, July 21, 2020 12:02 PM To: Craig Topper Cc: Chen, Yuanfang; Nicolai Hähnle; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen driven by new pass

Hello, We have a user that wants to get the code coverage report for his library without turning on instrumentation for the library clients or change how they are built (only the library is instrumented). It seems like the inline member functions defined in headers are not instrumented in this case because the clients are not instrumented. The library itself does not have a copy of the inline