[PATCH] D11214: [PM/AA] Remove the addEscapingUse update API that won't be easy to directly model in the new PM.

Chandler Carruth chandlerc at gmail.com
Fri Jul 17 20:26:04 PDT 2015


chandlerc added a comment.

Thanks Pete and Gerolf for the review. Submitting shortly.

In http://reviews.llvm.org/D11214#205912, @Gerolf wrote:

> I don't know this code well enough for a quality review. Certainly agree with the notion that this is a very brittle interface that is hard to maintain. And I trust your judgement that the original intent it was invented for is now obsolete. LGTM with these constraints. Also, as a bit orthogonal issue, but since you argue with ease of migration to the new pass manager (NPM): do you have a list of (potentially) performance relevant passes that could run into integration issues down the road? I suspect more(similar) performance-stability trade-offs on the road to NPM. Thanks!


I think I'm running out of things that will actually be substantially different between the two. AA was very near the bottom of the pile, and most of the others I've been able to fix without regressions.

The only other big one is one I already know is coming (but that will be super hard). The call graph used to drive the inliner will be different between the two pass managers. Specifically, the NPM will end up with a more precise call graph (LazyCallGraph, its already in the tree) and this may cause some significant differences with how functions are visited in the CGSCC walk. Sadly, fixing these to be the same is also *hard*. But I'm hopeful that while the difference is theoretically significant it won't in practice cause substantial performance differences.


http://reviews.llvm.org/D11214







More information about the llvm-commits mailing list