similar to: optnone/skipping passes in the new pass manager

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

As a point of clarification, optnone is already being handled by the pass itself in the legacy implementation. The skip[IR unit] functions are provided by the pass base classes, and the attribute is checked there. This happens any time the legacy wrapper is run, no matter how it is run. Regarding the opt-bisect design, I’m not particularly fond of the managed static either, but I do want to

Hi Chandler, I am now working on a bisecting tool to find mis-optimization on LLVM. I found OptBisect a very useful option and hope to make it work on the new pass manager. I have several questions about it. 1. Any plans to apply codegen stage with new pass manager? IIUC, new pass manager only works for opt stage. However the OptBisect option tries to accumulate pass counts through opt stage

Hello all, After reading OptBisect and DebugCounter related code and playing bit around it I have following simple design: - Add a debug counter for opt-bisect. Initilize it against option -opt-bisect-limit=<limit>. - DebugCounter is a singleton class so can be accessed by both new and legacy passmanager. We may need few more static method like getCounterIdForName(std::string &Name)

Hi Vivek, can you elaborate why you're looking for a one-size-fits-all solution? What is the noteworthy benefit over adding a new-pm specific implementation? Several changes you mention are purely for the benefit of supporting the legacy PM (which already has a working, tried, and tested solution). E.g. `getCounterIdForName`, the FIXMEs you mention, and the callbacks. All of these are

Greetings! As the generic Pass Instrumentation framework for new pass manager is finally *in*, I'm glad to start the discussion on implementation of -opt-bisect through that framework. As it has already been discovered while porting other features (namely, -time-passes) blindly copying the currently existing legacy implementation is most likely not a perfect way forward. Now is a chance

Hi Andrew, We absolutely need to be able to generate executable programs using > opt-bisect, so some mechanism for not skipping required passes is needed. > It might be nice to have a mode where no passes are skipped and the IR/MIR > is dumped when the bisect limit is reached, but I don't see that as a > requirement. > At this point it makes no sense to worry about the code

Philip, It kinda depends on user expectations. What do you really expect as a result of your compilation when you set -opt-bisect-limit=X? Do you just get a resulting IR and scan for the bad pattern? Then you dont care about pass sequences and do brute-force bisect. Do you expect to get a runnable code at the end and check for buggy run-time behavior? Then you need to keep the passes that are

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

On Tue, May 1, 2018 at 10:52 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Hi Vivek, > > > > Have you read the mailing list threads on this topic? I don’t believe > we’re quite ready to make the switch yet. There was a discussion last > October about what was left to be done. I’m sure it has been discussed > since then too. Here’s a link to the start of

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 >

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

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,

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 10/01/2018 11:13 PM, David Greene wrote: > Philip Pfaffe <philip.pfaffe at gmail.com> writes: >> Sorry, but I strongly oppose to the road you're suggesting here. As I >> said before the Pass*Manager* is entirely the wrong place to handle >> OptNone, the absolutely the wrong design. It makes sense for function >> *only*, and immediately breaks down everywhere

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

> 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

On 10/02/2018 01:17 AM, Kaylor, Andrew wrote: > Some of the issues we're talking about were also considered when I did the initial implementation of OptBisect. If anyone wants to look at the relevant reviews they can be found here: Thanks for sharing these, very useful! > https://reviews.llvm.org/D18576 (Abandoned first attempt) > https://reviews.llvm.org/D19172 (Committed second