[PATCH v2] mscoree: Implement VTable fixup for x86_64 architecture.

[Vincent Povirk]

> 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.unmanagedfunctionpointerattribute.unmanagedfunctionpointerattribute.aspx

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.