similar to: [RFC] Introducing classes for the codegen driven by new pass manager

-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

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

(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, The current plan is to prioritize enabling the NPM as soon as possible, and that includes addressing any blockers that are known or arise. This means prioritizing those blockers over other LLVM work. The current umbrella bug is PR46649 <https://bugs.llvm.org/show_bug.cgi?id=46649>. Philip's point is spot on that we are deficient now in the testing of the LegacyPassManager,

FWIW I'm in favor of this direction while making sure that we keep focus on removing the vestiges of the old pass manager for the code health impact to the project. -eric On Wed, Jul 22, 2020 at 3:15 PM Philip Reames via llvm-dev < llvm-dev at lists.llvm.org> wrote: > (I'm probably going to derail your thread, sorry about that.) > > I think at this point, we should just

On Fri, Jul 24, 2020 at 12:54 PM Sjoerd Meijer <Sjoerd.Meijer at arm.com> wrote: > Hi Alina, > > I think this is an excellent direction, this is the direction we should > take here. Just a somewhat irrelevant disagreement on this though: > > > Philip's point is spot on that we are deficient now in the testing of > the LegacyPassManager, > > I disagree

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

I have a whole slew of questions about optimization passes. Answers to any or all would be extremely helpful: How important are doInitialization/doFinalization? I can't detect any difference if I use them or not. Why does the function pass manager have doInitialization/doFinalization, but the global pass manager doesn't? If I am applying the function passes to many functions, do I

Sorry for the triple-posting! :-$ On 02/14/2013 04:30 PM, Yiannis Tsiouris wrote: > On 02/10/2013 08:47 PM, Yiannis Tsiouris wrote: >> After rebasing my local LLVM repo to ToT, I noticed that the >> finishAssembly function is not executed and, thus, the stack map is not >> printed at all. >> >> Is this a known issue or I 'm doing something wrong? >>

Hi Pedro (et al.), On 02/14/2013 11:43 PM, Pedro Artigas wrote: > I believe what is going on is that there is an issue with the way that information is deleted (the CG information). Yeap, that's exactly the problem! :-) I noticed that the GCModuleInfo::iterator (line 931 in lib/CodeGen/AsmPrinter/AsmPrinter.cpp) is empty and, thus, GCMetadataPrinter::finishAssembly is never called.

On Sun, Dec 16, 2012 at 7:23 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Stephen, > > > On 13/12/12 18:58, Stephen McGruer wrote: > >> I'm wondering if the documentation for LoopPass >> (http://llvm.org/docs/**WritingAnLLVMPass.html#**LoopPass<http://llvm.org/docs/WritingAnLLVMPass.html#LoopPass>) >> is misleading or >> incorrect (or

Hi, I would like to run the -O1 pass sequence followed by -reg2mem from an out of tree project which uses llvm. I am using the following code snippet to do so but in some cases, my method is also vectorising the code, which doesn't happen when running the same sequence(-S -O1 -reg2mem) through opt. Can someone please help me find what I am missing? Thanks, Akash. *

Are LoopPasses allowed to maintain state between runOnLoop invocations? The documentation is not clear on this point. -Dave

I wonder in what cases FunctionPass is better that Pass. For example, addPassesToEmitAssembly takes PassManger and addPassesToJITCompile takes FunctionPassManager. Another question is about FunctionPassManager::run(Function&) and FunctionPass(Function&). The former calls the later, which is fine, but the latter looks like this: bool FunctionPass::run(Function &F) { if

On 5/6/15 10:19 AM, Kuperstein, Michael M wrote: > > Hello Cristiano, > > I don’t think doFinalization() is really meant to be used this way. > My understanding is that doInitialization() and doFinalization() are designed specifically for modifying the LLVM IR (otherwise, why would a mutable reference to the Function be provided)? If that is not the case, then there is either a

Hi, I would like to give a quick update on what my current design and implementation go like. Basically, the `FunctionToLoopPassAdaptor` is now modified to a generic version `FunctionToLoopUnitPassAdaptor`, which allows re-using the existing codes to implement `FunctionToLoopNestPassAdaptor`, with the help of additional metadata associated with `Loop` and `LoopNest`. Both

Larry, On Wed, Aug 11, 2010 at 4:55 PM, Larry Gritz <lg at larrygritz.com> wrote: > I have a whole slew of questions about optimization passes. Answers to any > or all would be extremely helpful: > > How important are doInitialization/doFinalization? Most of the passes do not use them. > I can't detect any difference if I use them or not. Say, if you are writing

Hello Yiannis, I believe what is going on is that there is an issue with the way that information is deleted (the CG information). Right now there is a pass whose only job is to delete that information (CGInfoDeleter) and that pass deletes the info before the AsmPrinter has a chance to call the finishAssembly function. Right now the order that the doFinalization is called on passes is the reverse

Hi Stephen, On 13/12/12 18:58, Stephen McGruer wrote: > I'm wondering if the documentation for LoopPass > (http://llvm.org/docs/WritingAnLLVMPass.html#LoopPass) is misleading or > incorrect (or if I'm just missing something.) The documentation states: > > "The doFinalization method ... is called when the pass framework has finished > calling runOnLoop

I'm wondering if the documentation for LoopPass ( http://llvm.org/docs/WritingAnLLVMPass.html#LoopPass) is misleading or incorrect (or if I'm just missing something.) The documentation states: "The doFinalization method ... is called when the pass framework has finished calling runOnLoop<http://llvm.org/docs/WritingAnLLVMPass.html#runOnLoop> for every loop in the program being