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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
