[llvm-dev] OptBisect implementation for new pass manager

[Kaylor, Andrew via llvm-dev]

> from the sidelines it seems like one readily understandable model for OptBisect is "go this
> far down the regular pipeline then turn on OptNone."

That’s a pretty good starting point for understanding what OptBisect is supposed to be doing IMO. It’s not literally that since it has to apply to module passes and SCC passes, but from a conceptual point of view that’s a reasonable way to think about it.

-Andy
From: paul.robinson at sony.com [mailto:paul.robinson at sony.com]
Sent: Friday, September 28, 2018 12:46 PM
To: Kaylor, Andrew <andrew.kaylor at intel.com>; philip.pfaffe at gmail.com
Cc: dag at cray.com; llvm-dev at lists.llvm.org
Subject: RE: [llvm-dev] OptBisect implementation for new pass manager

> Mixing OptNone and bisect is a software engineering bug: it's mixing different layers of abstraction. Bisect is something that's
> at pass manager scope: run passes until whatever. OptNone in turn doesn't belong in the pass manager layer. It only concerns
> function passes, and crumbles quickly considering other IRUnits or even codegen. I don't have a clear vision what OptNone
> handling should look like, but at this point I consider it entirely orthogonal to bisect handling.

In one sense you are absolutely right, OptNone and opt-bisect are completely different things, but from the perspective of the pass they mean exactly the same thing: should I optimize this IR unit. It’s also true that the pass shouldn’t be making that decision, and it really isn’t in the legacy implementation. It’s calling a function to ask whether or not it should perform the optimization. That’s also less than ideal. In a perfect world, the pass wouldn’t be called at all if it should be run. I think we’re actually in agreement here with regard to OptBisect.

OptNone is out of the scope of the current proposal, but I agree that in principle the pass manager shouldn’t be handling it. On the other hand, it’s not entirely clear to me that the pass itself should be handling it. There is nothing pass-specific in the interpretation of the OptNone attribute. The OptNone attribute says “don’t optimize this function.” So should we really be calling the run() method of an optimization pass on a function that we aren’t supposed to be optimizing. It feels to me like there’s a missing player here.  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.

Some historical perspective and clarification:

OptNone does not mean "don't optimize this function."  It means "treat this function as much like –O0 would as you can."  (We thrashed that one out when LTO started tagging functions with the optnone attribute.)  Those are not completely identical statements; -O0 does run some passes. Complications arise because there's only one pass pipeline in any given compilation, and the pass manager doesn't know what the –O0 pipeline looks like, but the –O0 pipeline is not empty.

Passes that don't normally run at –O0 were taught to query the helper. This was not the originally proposed design, but at the time we introduced OptNone there was serious push-back about adding a new feature to the old (at that time, only) pass manager because the new pass manager was just over the horizon.  Five years later it might be time to rethink that.

OptBisect built on OptNone because it was there.  Again there are passes that have to run to produce usable output, even if you might think of them as "optimization" passes, they would be part of the –O0 pipeline anyway and they pretty much have to run no matter what.  I'm not close enough to the problem to have a strong opinion whether OptBisect and OptNone should share an underlying mechanism, but from the sidelines it seems like one readily understandable model for OptBisect is "go this far down the regular pipeline then turn on OptNone."  Maybe a different model would work better; I'm not sure.
--paulr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180928/064f1edb/attachment.html>