rsmith added a comment. In D99517#2667025 <https://reviews.llvm.org/D99517#2667025>, @rjmccall wrote:
> You should structure this code so it's easy to add exceptions for certain > calling conventions that can support tail calls with weaker restrictions > (principally, callee-pop conventions). Mostly that probably means checking > the calling convention first, or extracting the type restriction checks into > a different function that you can skip. For example, I believe x86's > `fastcall` convention can logically support any combination of prototypes as > `musttail` as long as the return types are vaguely compatible. The LLVM `musttail` flag doesn't seem to allow for any target-specific loosening of the rules at the moment, so I don't think we can get any benefit from such restructuring right now; do you think it's OK to defer this restructuring and use the stricter rules across all targets for now? I think there is also value in having a target-independent set of restrictions, even if we could actually guarantee tail calls in more circumstances on some (or maybe most!) targets, in order to allow people to make portable use of the attribute and as data towards something that we might be able to standardize. (For example, the people working on coroutines in C++ wanted something like this, but wanted feedback from implementers on what set of restrictions would be necessary in order to portably guarantee a tail call.) In order to strike a balance between portability and usefulness here, maybe we could plan to eventually accept any musttail call we know the target can support, but warn on musttail calls that don't satisfy the stricter rules and therefore may be non-portable? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D99517/new/ https://reviews.llvm.org/D99517 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
