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