phoebewang wrote: > I sort of understand the logic of "we need a calling convention, fastcc isn't > useful on x86-64, let's repurpose it". But there's a significant benefit to > giving a calling convention with unusual semantics (like, it only works on > targets that have APX enabled) its own name; it's less confusing, and it > cleanly allows future extensions for all targets. And introducing a new > calling convention really isn't that much more work.
I'm afraid I disagree. Notice the minor difference between `X86_FastCall` and `Fast` in X86CallingConv.td. Out of cautious, I think mixing up a internal only fastcc with an external named calling convention is not a good idea. A internal only calling convention has more freedom, since it's limited to the single CU. It dones't have backward and cross compilation compatibility constraints the traditional calling convention have. > It isn't likely the set of integer registers on x86 will change again, but > floating-point/vector registers have been getting constant updates. The current floating-point/vector calling convention uses 8 registers for argument passing, and they are less common than GPRs (since we use them to pass PTR and/or large type like i128 etc.). So I don't think it's a problem is short time. AVX512 has extended total register number from 16 to 32 for more than a decade. I don't see a request to change fastcc for it :) 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! https://github.com/llvm/llvm-project/pull/164768 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
