similar to: Porting OptBisect to New Pass Manager

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

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 >

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

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

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

On 10/01/2018 08:39 PM, David Greene wrote: > "Kaylor, Andrew" <andrew.kaylor at intel.com> writes: > >> What if in the registration interface we had three options: skippable, >> not skippable, and run at OptLevel::None. > I kind of like this idea. If necessary, the pass could even query the > target (or some other entity) about what OptLevel::None means.

On 09/28/2018 12:25 AM, Kaylor, Andrew wrote: > As I said, that’s really outside the scope of the current discussion > except to say that the relevant question is what component should make > the decision about whether or not a pass should be run. A planned way of implementation for new-pm's OptBisect is for instrumenting object to control the execution. Whenever instrumentation

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 else. Frankly, OptNone should take no role in this particular discussion, and I feel like so far it has because "We've always done

What if in the registration interface we had three options: skippable, not skippable, and run at OptLevel::None. We'd need some way to communicate the OptLevel::None to the pass, but that doesn't seem terrible. -Andy -----Original Message----- From: David Greene [mailto:dag at cray.com] Sent: Monday, October 01, 2018 7:01 AM To: Fedor Sergeev <fedor.sergeev at azul.com> Cc:

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

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

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)

> Pass Manager (PassManager.h) itself, does not - it's only templates, none of it depends on Region, Loop, etc. Well, true but the problem happens when you try to instantiate the thing. And for generic features like opt-bisection, ir-print-after-all etc that want:   - to have a say before/on/after every execution of every pass   - have a shared implementation of the main logic you have

On Tue, Apr 3, 2018 at 8:50 AM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > > Pass Manager (PassManager.h) itself, does not - it's only templates, > none of it depends on Region, Loop, etc. > Well, true but the problem happens when you try to instantiate the thing. > And for generic features like opt-bisection, ir-print-after-all etc that > want: > - to

Ping on this - any chance we can look at fixing the OptBisect layering here/now? Could we move the implementation into Analysis & require users to set it, rather than having it as a default value in IR? On Tue, Apr 3, 2018 at 9:25 AM David Blaikie <dblaikie at gmail.com> wrote: > On Tue, Apr 3, 2018 at 8:50 AM Fedor Sergeev <fedor.sergeev at azul.com> > wrote: >

David, we definitely need to address this issue and I did not forget about it. I'm still fleshing out a proposal on a generic solution for "pass execution control points", which was inspired by the new pass manager needs but then it appears we can largerly reuse the implementation for both managers. Since the implementation should be based on a special Analysis, it definitely

Hi all, Debugging a mis-compilation is always time consuming. I recently did some attempt on bisecting bad pass for LLVM and would like to share some ideas about how do we make it work. And meanwhile, I would also encourage the community to make each pass more bisectable with help of DebugCounter. We have already got a very useful helper in LLVM for pass level bisection, which is OptBisect

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

Care to expand a bit on what you mean by per-optimization level? Preferably with a use case. To me optbisect is a low level developer tool and it doesn't cope well with a crude user level hammer of optimization level. F. On Fri, Jun 8, 2018 at 9:12 AM +0300, "Zhizhou Yang" <zhizhouy at google.com<mailto:zhizhouy at google.com>> wrote: Hi Fedor, Thanks for replying