[clang] [llvm] [GlobalOpt] Add TTI interface useFastCCForInternalCall for FASTCC (PR #164768)

[Eli Friedman via cfe-commits]

efriedma-quic wrote:

"fastcc" was originally invented in the context of targets with a single calling convention, but where that calling convention had significant limitations.  Like, on 32-bit x86, the default "C" calling convention passes everything on the stack.  So it's basically supposed to be a variation on the C calling convention: assuming the same underlying machine constraints, but ignoring bad decisions made when the ABI documents were originally written.

The x86-64 ABI developers learned those lessons, so fastcc is just the C calling convention; we didn't need to modify it.

If we have new architectural features, and we want a different calling convention for machines that have the feature, versus machines which don't have the feature, I think we need more specific names for those calling conventions.  Having the C calling convention vary based on per-function target features is a constant source of problems for interprocedural optimizations.  We don't want to extend those same problems to fastcc.

I think, if you want to pass arguments using APX registers, you should introduce a new "APX" calling convention.  Probably from there, instead of a boolean useFastCCForInternalCall, you want a function `CallingConv getOptimalCCForInternalCall(CallInst &CI)`, or something like that, to pick whatever calling convention the target prefers based on the available caller/callee target features, and maybe other heuristics.

https://github.com/llvm/llvm-project/pull/164768