[PATCH] D15289: Avoid inlining CallSites leading to unreachable

[Jun Bum Lim via llvm-commits]

junbuml added a comment.

> Note on windows "main" may be "wmain" "WinMain" "WINMAIN" "MAIN" "AfxWinMain" "ENTGQQ" etc.


I'm not sure if it make sense to add all these names here. Is there any existing function to find an entry point for Windows? Please let me know any suggestion?

> I've tried doing things like this in the past and it is tricky to get right outside of benchmarks. For instance we had performance-sensitive loops postdominated by calls to exit(). (And if you think interprocedurally, everything is generally postdominated by a very infrequently taken exit point).


I agree this could happen. So, I think we cannot blindly assume that all unreachable-terminated blocks are rarely executed. This is also the case in BranchProbabilityInfo::calcUnreachableHeuristics(). However, it might be still reasonable to assume that EH paths are less frequently taken in general so that we can inline little conservatively when call sites are post-dominated by EH code. So instead of detecting all unreachable blocks, we can limit the search only for blocks post-dominated by EH code (e.g., throw ()) ?

> Using BPI or similar is better in that at least all the parts of the framework can agree on the criteria for what is relative hot and what is relatively cold. As I told our devs, if you think you know better, please work to enhance the static heuristics or the profile count maintenance so every part of the code can benefit.


I agree using BPI with some general heuristic here and enhancing BPI itself must be a right approach in general. But, I prefer to take incremental changes as long as the basic idea and direction is reasonable.

> Also there are lots of cases where inlining in cold paths is helpful to improving CQ on hot paths. But that's a discussion for another day, perhaps.


Can you give me more detail about this?


http://reviews.llvm.org/D15289