phoebewang wrote: I don't fully agree with the points. If fastcc is just (and always) the C calling convention, it means its existence is meaningless. I agree with its original intention and a well designed ABI doesn't need it at all. But it is the exactly reason why we retargeting it for APX. We are solving (almost) the same problem: a single calling convention has its design limitations. The difference is just, for 32-bit, it's bad design at the beginning; for APX, the design cannot fit the new feature. So, IMO, using fastcc for APX is the best choice.
The way to use `getOptimalCCForInternalCall` looks like over engineering to me. I can't say for other targets, but I believe we don't have the need to introduce a second fastcc in 5 years on x86. Noting, we actually has a `x86_fastcallcc` that used for C's `fastcall`. We neither use it for fasscc as you suggested, nor invent a second fastcc for so many years. https://github.com/llvm/llvm-project/pull/164768 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
