MSDN says:

Quote

In addition to the type aliases, you must also use the XM_CALLCONV annotation to make sure the function uses the appropriate calling convention (__fastcall versus __vectorcall) based on your compiler and architecture. Because of limitations with __vectorcall, we recommend that you not use XM_CALLCONV for C++ constructors.

But what about functions who just return XMVECTOR or XMMATRIX without accepting parameters of these type aliases?

Should one write:

XMVECTOR XM_CALLCONV f();

or

XMVECTOR f();

?

Quote

Results of __vectorcall functions are returned by value in registers when possible. Results of integer type, including structs or unions of 8 bytes or less, are returned by value in RAX. Vector type results are returned by value in XMM0 or YMM0, depending on size. HVA results have each data element returned by value in registers XMM0:XMM3 or YMM0:YMM3, depending on element size. Result types that don't fit in the corresponding registers are returned by reference to memory allocated by the caller.

Explained it.

Are you actually gonna write code that has these prefixes?

Have you checked if the compiler doesn't pass them in register by default? I never bothered to check this, but could be interesting. If it doesn't I'm not sure I'd start using it anyway because it's ugly.

22 hours ago, turanszkij said:

Are you actually gonna write code that has these prefixes?

I would.

22 hours ago, turanszkij said:

Have you checked if the compiler doesn't pass them in register by default? I never bothered to check this, but could be interesting. If it doesn't I'm not sure I'd start using it anyway because it's ugly.

It is always an error to prioritize subjective aesthetics over functionality.
It is always a mistake to ask permission from your compiler to implement a hack or "alternative" code.

Checking that something works on your compiler only proves that it works as intended on one compiler.  They literally gave a warning that without using this macro as a calling convention your code might not run correctly depending on your compiler and architecture.

It is never valid to hinder code's portability simply because of your subjective views on aesthetics.


L. Spiro

On 11/30/2017 at 11:26 PM, turanszkij said:

Are you actually gonna write code that has these prefixes?

I already did. I also use all the XMVECTOR and XMMATRIX aliases. I only missed adding the calling convention for the return statement, but that is fixed now as well.

With and without the calling conventions: https://blogs.msdn.microsoft.com/vcblog/2013/07/11/introducing-vector-calling-convention/

Though, if you only want to support x64, you can use a compiler flag.

On 11/30/2017 at 11:26 PM, turanszkij said:

because it's ugly.

Fair point (though I like the coloring of macros in my solarized dark styled editors). It becomes difficult maintaining lines of at most 80 character while still having well structured code.

As a side note, look at this "ugly" header of mine. Though it performs a very good job

3 minutes ago, matt77hias said:

With and without the calling conventions: https://blogs.msdn.microsoft.com/vcblog/2013/07/11/introducing-vector-calling-convention/

I need to get up to date on this, thanks for that article!

17 hours ago, L. Spiro said:

Checking that something works on your compiler only proves that it works as intended on one compiler.  They literally gave a warning that without using this macro as a calling convention your code might not run correctly depending on your compiler and architecture.

This is also one of the reasons. If you pass XMVECTOR or XMMATRIX by value, you will have errors for x86. The alternative is using pass by reference, but that results in performance loss. Furthermore, Intel XEON processors will benefit a lot.

As a second side note based on the uglyness, I really consider using SAL annotations (really ugly looking code IMHO) some day as a guidance for my compiler .