[PATCH] D101231: [RFC][InlineCost] Don't count the cost of trully exceptionally unlikely blocks (PR50099)

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri created this revision.
lebedev.ri added reviewers: aeubanks, eraman, Prazek, davidxl, kazu, mtrofin.
lebedev.ri added a project: LLVM.
Herald added subscribers: haicheng, hiraditya.
lebedev.ri requested review of this revision.

Cost-benefit analysis already did something like that, but different,
off by default, and needs a profile (as opposed to being happy with static weights).

In PR50099 i reported that NewPM switch introduced a rather large regression in one benchmark.
That happens because certain destructor call is determined to be cold,
so it is given smaller inlining budget (45), and it's inlining cost measure at ~55.

We could either raise budgets, or lower costs.
D101228 <https://reviews.llvm.org/D101228>, and potentially D101229 <https://reviews.llvm.org/D101229> does the former.
Here i propose to investigate one approach for the latter.

The large portion of that destructor is exception handling,
and as per block frequency it is *exceptionally* unlikely to execute.
So i propose to introduce a `impossible-code-rel-freq` option,
defaulting to 2 parts per million (that is the smallest one to do the job)
of function's entry frequency, and saying that if the block's frequency
is less than that, then it is impossible to execute,
and not adding the costs of instructions in said block.

Does this sound completely insane? Thoughts?


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101231

Files:
  llvm/lib/Analysis/InlineCost.cpp
  llvm/test/Transforms/Inline/X86/impossible-block.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D101231.340272.patch
Type: text/x-patch
Size: 8171 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210424/1c2fc002/attachment.bin>