Cranelift: implement Windows(Fastcall) in VCode

[yurydelendik]

The issue is a part of #2079 (and possibly #1642 ?). The issue needs to be extended to all new backends (x64 and aarch64). This will require implementing the win64 fastcall ABI (or "mostly AArch64 EABI") support in cranelift/codegen/src/machinst/ to fix e.g. tests/all/traps.rs tests.

[cfallin]

AFAIK, aarch64 doesn't have a separate fastcall ABI (at least according to this doc) -- @peterhuene can you confirm?

[yurydelendik]

aarch64 doesn't have a separate fastcall ABI

MS docs refer it as "mostly AArch64 EABI". Will we call it CallConv::SystemV or will add different values?

[cfallin]

I read through the doc and compared it to the standard AArch64 ABI; it seems that all of the basic details are the same (register roles, stack requirements, etc.). The only differences I spotted were that the AArch64 ABI specifies FPCR (FPU control register) is undefined and must not be modified, while Windows specifies it is callee-save; and that Windows has its own exception unwind, of course. The FPCR difference shouldn't matter as we never modify the register.

So as far as I can tell, we can just use the SystemV ABI for Windows on AArch64, but others please do say something if that's wrong!

[peterhuene]

I believe your assessment of the calling convention is correct: it won't differ from the AArch64 ABI in ways that concern Cranelift.

However, I think we'll need a different CallConv value for Windows "ARM64" to differentiate the unwind information.

While we're there, I would love for us to stop calling it "Windows fastcall" instead of "Windows x64" in Cranelift, but that ship has probably sailed.

[peterhuene]

I guess we could also just rename WindowsFastcall to simply Windows and use the same value for both x64 and ARM backends for unwind information generation. "Fastcall" just leaves a x86 taste in my mouth.

[yurydelendik]

I guess we could also just rename WindowsFastcall to simply Windows

Yeah, I am counting we will do just that.

[alexcrichton]

I believe fastcall is now implemented, so I think this can be closed.