[PATCH] D30651: [InlineCost, -Oz] Don't take into account the penalty of a fast call of frequently used functions

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

> Based on this we can expect fast calls will have minimized call overhead.

That's true, in some sense... but that's also true for the C calling convention in most cases.

> If it makes no sense why functions are marked as fastcc so aggressively. I think not all calls of them can actually be made as fastcc.

It's better to think of fastcc as the default calling convention for everything where the LLVM optimizer controls the calling convention.  It passes values in registers where it makes sense, and tries to strike a reasonable balance between caller-save and callee-save registers.  We use it over the C calling convention where we can so that we aren't stuck doing stupid things, like passing everything on the stack on x86-32, or shuffling floating-point values between integer and VFP registers on ARM with a softfp abi.  It doesn't really indicate anything about the absolute overhead of a call.



================
Comment at: lib/Analysis/InlineCost.cpp:1219
+  Function *Callee = CS.getCalledFunction();
+  return (Callee->getNumUses() >= static_cast<unsigned>(FrqFuncThreshold));
+}
----------------
getNumUses() isn't going to return anything useful unless the function has internal linkage; even if a function only has one or two uses in the current file, it's likely to have more uses in other files the compiler can't see.


https://reviews.llvm.org/D30651