On 01/22/2016 11:45 PM, Vincent Povirk wrote:
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.
Is it the same for managed C++? If you say __vectorcall support is not needed I will of course remove this code.
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.
If they do not support it they should just issue compiler warning, or am I missing something? Clang may hopefully add the suport. msvc is very unlikely to compile Wine soon I guess. Intel Compiler does not support ms_abi attribute at all and thus compiling wine 64bit with it is totally not feasible for now.
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 can guess it might be just nearly as likely as without .NET. See this bug: https://bugs.winehq.org/show_bug.cgi?id=27680: there is 7-8 apps w/o .NET known so far. As I got from brief googling native .Net should not suffer from stack misalignment. So I thought it won't hurt to add an attribute to ReallyFixupVTable (which presumably will be universally supported some day) , but considered too much forcing alignment right in the thunk.
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.
Are you sure they are going to crash? I looked at the code produced by 'mono --aot' on my short class, they are not storing xmm regs routinely to stack at prolog. Our ms_abi functions do that just because they call non-msabi functions and this is not the case for mono which has ms-abi through all the code, they do not need to do that unless the function modifies non-volatile XMM registers. Even if they do store on stack in this case, they could do it through unaligned instructions or fix stack alignment in such function.