[PATCH] D65410: [PassManager] First Pass implementation at -O1 pass pipeline

Mon Aug 19 22:47:09 PDT 2019

echristo added a comment.

In D65410#1617366 <https://reviews.llvm.org/D65410#1617366>, @probinson wrote:

> The goal from the original email was:
>
> > The design goal is to rewrite the O1 <https://reviews.llvm.org/owners/package/1/>
> >  optimization and code generation pipeline to include the set of
> >  optimizations that minimizes build and test time while retaining our
> >  ability to debug.
>
> "Retaining our ability to debug" is a more constraining goal than Chandler's "coherent backtraces for test / assertion failures."  A good debugging experience comes from good variable-location information, and minimal reordering of instructions.  This is different from "don't mess with my stack frames" which lets you do pretty much anything that doesn't involve a call.
>
> Without presuming to speak for Eric, I don't think there was an explicit goal to make O1 <https://reviews.llvm.org/owners/package/1/> look like a stripped-down O2 <https://reviews.llvm.org/owners/package/2/>?  But certain pass orderings make sense, and so where the same passes occur, the same ordering would be pretty likely. So, building an O1 <https://reviews.llvm.org/owners/package/1/> pipeline by erasing some stuff from the O2 <https://reviews.llvm.org/owners/package/2/> sequence makes some sense, because it's the practical thing and not because it's a goal to do it that way.

Not an explicit goal of a stripped down O2 <https://reviews.llvm.org/owners/package/2/>, but honestly probably not too far off.

(further below)...

> As for specific pass choices:  Based on the data from Greg Bedwell's lightning talk last year (https://llvm.org/devmtg/2018-04/talks.html#Lightning_11) the three worst offenders for debuggability were LICM, InstCombine, and SROA.  It looks like this patch does exclude SROA but not the others?  Or at least not all cases of LICM.
> 
> I'd suspect that SROA's main problem is that we don't do a good job of tracking broken-up fragments (the original SROA rewrite didn't even try, IIRC), and if the pass has a good compile-time versus run-time benefit, it's worth investing in making that work better.
>  LICM just inherently interferes with smooth debugging; it's hard to do anything useful with loops that remains nicely debuggable. 
>  I don't know what InstCombine's problem is.

Smooth is going to be somewhat subjective and there's some work in instcombine (rnk took a stab at it and is currently reviewing a pretty good patch I think in this area). SROA just needs some tracking work if there are still problems.

Now LICM - this is one of those I've gone back and forth on and I'd like to see what debugging and performance look like with and without. I like the general perspective of "remove the abstraction penalties" as an O1 <https://reviews.llvm.org/owners/package/1/>/Og sort of thing. That said, ultimately something that people are able to use to debug their code is the ultimate goal - it won't be 100%, but as good as we can make it in the general case.

At any rate, this is just a first pass through both the individual passes are going to need work for debugging as is the particular pipeline.

-eric

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65410/new/

https://reviews.llvm.org/D65410