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

[Chandler Carruth via Phabricator via llvm-commits]

chandlerc added a comment.

In https://reviews.llvm.org/D30651#693607, @efriedma wrote:

> > 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.


Agreed.

I suspect that the underlying problem is some combination of imprecise modeling of call overhead and failing to account for low numbers of call sites that aren't exactly one.

I suspect that there would be more general (and still quite easy) fixes for the call overhead modeling, and some tuning of heuristics around the number of call sites seems like a good idea much as Eli suggested.


https://reviews.llvm.org/D30651