[PATCH] D116036: [Inline][X86] Avoid inlining if it would create ABI-incompatible calls (PR52660)

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Dec 22 01:42:24 PST 2021


nikic added a comment.

In D116036#3206048 <https://reviews.llvm.org/D116036#3206048>, @pengfei wrote:

> The fix seems good. Just two concerns here:
>
> - I wonder what's the algorithm when inlining. Given we have a calling chain A->B->C. If we can inline both B and C into A, is B inlined firstly to A, then C to AB, or C inlined firstly to B, then BC to A? I'd worry if we are pessimistic for the former case.

With few exceptions, inlining happens bottom-up, so B->C will be inlined first and then A->BC. So calls in the callee will already be eliminated, unless they can't be inlined for some reason (noinline, cost etc).

> - Another concern is the compiling time. Scanning seems inevitable, but can we avoid to repeat scanning if the inlined function is called in many place?

I think this will not have much practical impact mainly because this kind of target feature mismatch is rare. Usually target features on all functions are the same. Inlining already does multiple scans of the callee, so at least this doesn't change anything asymptotically.


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

https://reviews.llvm.org/D116036



More information about the llvm-commits mailing list