similar to: New pass manager for optimization pipeline status and questions

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

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,

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

-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

(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

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

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,

(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

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

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`. However, until NPM is enabled by default, we still want tests using opt to use the legacy PM by default. We could attempt to make `-passes=` work with the legacy PM and have a legacy vs new PM flag, but given the design/syntax of

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

Hmm it looks like getting NPM to work with opt is non-trivial. Only a small portion of the opt functionality works with NPM :( On Mon, Jun 8, 2020 at 3:36 PM Robinson, Paul <paul.robinson at sony.com> wrote: > Maybe you could change the default PM in opt and see what fails? > > --paulr > > > > *From:* Arthur Eubanks <aeubanks at google.com> > *Sent:* Monday,

> On Jun 24, 2020, at 19:17, Arthur Eubanks <aeubanks at google.com> wrote: > > > > On Wed, Jun 24, 2020 at 12:23 PM Philip Reames <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > > > On 6/24/20 11:21 AM, Matt Arsenault via llvm-dev wrote: >> >> >>> On Jun 24, 2020, at 14:13, Arthur Eubanks via

Hi, As part of new pass manager work, I've been trying to get something like `opt -foo` working under the NPM, where `foo` is the name of a pass. In the past there's been no reason to keep the names of passes consistent between NPM and legacy PM. But now there is a reason to make them match, so that we don't have to touch every single test that uses `opt`. There are a couple of

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

On 6/24/20 11:21 AM, Matt Arsenault via llvm-dev wrote: > > >> On Jun 24, 2020, at 14:13, Arthur Eubanks via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi, >> >> As part of new pass manager work, I've been trying to get something >> like `opt -foo` working under the NPM, where `foo` is

On Mon, Jun 8, 2020 at 7:11 AM Robinson, Paul <paul.robinson at sony.com> wrote: > When the optnone design was being discussed, Chandler specifically > rejected having the pass manager involved in the decision (which was the > original proposed design). Assuming he still feels the same way now, if > the existing `skipFunction` calls aren’t being executed under the new 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

Just tested it out, that test does indeed fail under the old PM at -O3 and even at -O2. If the ASan pass runs after optimizations and is designed to detect undefined behavior at runtime, I don't see how it can be super reliable at higher optimization levels. On Wed, May 13, 2020 at 12:39 PM David Blaikie <dblaikie at gmail.com> wrote: > +some sanitizer/new pass manager folks >