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

[Alex Bezzubikov via llvm-commits]

zuban32 wrote:

> > A function could be external before LTO stage, and become internal only after LTO symbol resolution. I.e. we're linking against some older object file which has the function compiled with some older definition of the target feature, and the calls to that function in a new module would still become fastcc.
> > That's still quite an artificial case IMO.
> 
> LTO works on LLVM bitcode files, which must be (re-)compiled during linking. The LTO stage changes default CC to fastcc on both sides, and the backend fastcc lowering happens after it, so both will use the new fastcc. There's not a chance to link to the old protocol.

Ok, just let me describe what I'm talking about in more details, I'm not convinced that's impossible yet.

Assume we have two modules: `mod1` containing `foo` and `mod2` containing `bar`, where `foo` calls `bar`. Then

1. We compile `mod2` with `-c -flto` and `F` target feature enabled, and store it somewhere as some sort of a library, e.g. some offload compilation builtin library as a part of a compiler package.
2. After 2 months (assume in that time **we have slightly changed the definition of the feature `F`**) we compile `mod1` with a new compiler and try to link it with LTO enabled against that old `mod2` module we compiled at step 1. Correct me if I'm wrong, but isn't the `foo`->`bar` call still going to be set to fastcc?

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