phoebewang wrote: > > > Autoupgrade. If you read bitcode generated by an old version of LLVM, > > > does it still have the same meaning? > > > I think 1&3 are not real problems. fastcc are internal only calling > > convention within a module. > > I think technically it's still possible to have a problem if we later change > the definition of the CC we're substituting `fastcc` with, and try to link > with the older object file. That means the implementation of `fastcc` for > that particular feature we're setting now should be set once and for all, > never to be touched later. > > And what if in the future we'll have another GPR extension on top of EGPR > affecting calling conventions?. It's highly unlikely that one'd want to link > against the old bitcode though.
No, there's not a problem AFAICT. The internal means all the functions' call graph are limited to the same object file. Different CCs can coexist, because there's no interconnection between one and another. Bitcode is not a problem either, because it will be compiled with the new CC. Neverthless, we should not change it arbitrarily. https://github.com/llvm/llvm-project/pull/164768 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
