search for: getcounteridfornam

...an 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 heavyweight changes, but I don't see an upside of going this direction. Cheers, Philip 2018-05-06 10:59 GMT+02:00 vivek pandya <vivekvpandya at gmail.com>: > Hello all, > > After reading OptBisect and DebugCounter...

...ted 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) etc. - Use it to decide if this pass is required to be executed or not. - For new passmaager just before executing run() for a pass we can check this counter. - For legacy pass manager we can directly use this debug counter in skipFunction()/skipModule() etc method. - There...

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