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

[Eli Friedman via llvm-commits]

efriedma-quic wrote:

> Nevertheless, I have moved the caller check logic to target code, and kept 64-bit generating fastcc as is. Besides, it keeps the ability to be forward compatible to newer calling conventions and a target independent fastcc in the middle end. Please take another look. Thanks!

So the rule is essentially, you can only use fastcc if the caller and the callee have the same target features?  I guess that works, but if we're going that route, I'd like to document it, and enforce it in a more consistently.

> @efriedma-quic I'm confused here a little bit, if fastcc is an internal LLVM convention which can only appear in the code when GlobalOpt considers it safe, why are we discussing it here as a sort of an established ABI that's been here for years?

The problem here isn't that the ABI has to stay the same across LLVM versions; we explicitly don't guarantee that.  But I do care about other forms of consistency:

- Consistency across targets.  If a calling convention is available on all targets, it should have a similar meaning on all those targets.
- Consistency across subtargets.  If a calling convention shows up in multiple places in a module, it should have the same meaning in all of those places.
- Autoupgrade.  If you read bitcode generated by an old version of LLVM, does it still have the same meaning?


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