Closed sorear closed 8 months ago
The general approach vendors have taken is to mangle non-standard function type modifiers (such as calling conventions) as vendor qualifiers, e.g. U9swiftcallFvvE
: https://godbolt.org/z/9rdK351xY
Such qualifiers are generally mangled whenever a full signature is mangled, such as when mangling a function type in nested positions, but not when mangling a function that happens to use the calling convention, since you cannot overload functions by calling convention. Does that work for you?
The general approach vendors have taken is to mangle non-standard function type modifiers (such as calling conventions) as vendor qualifiers, e.g. U9swiftcallFvvE: https://godbolt.org/z/9rdK351xY
Ah. I was under the mistaken impression that qualifiers could only be used for "pointer to function" and not for "function".
Such qualifiers are generally mangled whenever a full signature is mangled, such as when mangling a function type in nested positions, but not when mangling a function that happens to use the calling convention, since you cannot overload functions by calling convention. Does that work for you?
Yes. The request was only for nested positions.
Thank you!
While working on the RISC-V psABI for the vector calling convention, I hit a seemingly natural use case that the standard mangling rules don't seem to cover: overloading a function to support multiple callable types, and using it for functions with the same argument and return types but a different declared calling convention. The following is a demonstration of the issue that applies to 64-bit Arm on current clang:
Is this something that can and should reasonably be supported by a new ABI?
<function-type>
already reflects three kinds of variant calling convention, but none of them are extensible in a suitable way.