That's not quite true for __vectorcall convention. From your first link for XMM4,YMM4 for instance: "Must be preserved as needed by caller; *fifth vector-type argument when __vectorcall is used*". So to support all the possible cases we need to preserve all of them I suppose. That's why I added this mess with AVX detection and 2nd thunk version.
OK, I missed that.
But I don't think it's possible for a .NET method to use __vectorcall as its calling convention. The attribute used to specify it doesn't have a value for this: https://msdn.microsoft.com/en-us/library/system.runtime.interopservices.unma...
It's possible MS will extend this in the future, but it's also possible they'll make up entirely new calling conventions. I don't think they will, and for now I don't think it's worth the extra complexity.
The only potential problem I see with __attribute__((force_align_arg_pointer)) is that we may want to use compilers other than GCC (such as clang or msvc), and they may not support this attribute. I did see it used in some defines on the Mac (because it has stricter alignment requirements than Windows), so I guess it works in clang.
How likely do you think it is that there's code out there that calls a .NET method with wrong alignment? Maybe we don't need to worry about this.
I only took a quick look and could be wrong, but from looking at mono_arch_emit_prolog in mini-amd64.c it seems like Mono also assumes an aligned stack on entry to the functions it generates, meaning we'd get a crash eventually anyway.