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

Paul Robinson via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Aug 6 10:58:30 PDT 2019


probinson added a comment.

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.

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65410





More information about the cfe-commits mailing list