Stream: git-wasmtime

Topic: wasmtime / Issue #2372 Cranelift: implement WindowsFastca...

Wasmtime GitHub notifications bot (Nov 06 2020 at 15:32):

yurydelendik opened Issue #2372:

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 support in cranelift/codegen/src/machinst/ to fix e.g. tests/all/traps.rs tests.

Wasmtime GitHub notifications bot (Nov 06 2020 at 17:14):

cfallin commented on Issue #2372:

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

Wasmtime GitHub notifications bot (Nov 06 2020 at 17:58):

yurydelendik commented on Issue #2372:

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?

Wasmtime GitHub notifications bot (Nov 06 2020 at 18:29):

yurydelendik edited Issue #2372:

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.

Wasmtime GitHub notifications bot (Nov 06 2020 at 18:35):

cfallin commented on Issue #2372:

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!

Wasmtime GitHub notifications bot (Nov 06 2020 at 19:02):

peterhuene commented on Issue #2372:

I believe your assessment of the calling convention is correct, that being it won't differ from 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.

Wasmtime GitHub notifications bot (Nov 06 2020 at 19:02):

peterhuene edited a comment on Issue #2372:

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.

Wasmtime GitHub notifications bot (Nov 06 2020 at 19:14):

peterhuene commented on Issue #2372:

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.

Wasmtime GitHub notifications bot (Nov 06 2020 at 19:15):

yurydelendik commented on Issue #2372:

I guess we could also just rename WindowsFastcall to simply Windows

Yeah, I am counting we will do just that.

Last updated: Dec 23 2024 at 12:05 UTC