Wasmtime GitHub notifications bot (Apr 06 2020 at 23:37): Wasmtime GitHub notifications bot (Apr 06 2020 at 23:37):iximeow opened Issue #1475:
Cranelift should be able to compile x86 functions with stack frames requiring 240 bytes or more, when that also requires preserving a SIMD register. We've had to track an extension to the fastcall ABI that requires saving some, and due to Cranelift's choice in stack layout for these functions it's impossible to satisfy constraints required by Windows unwind information.
Benefit
Cranelift and its users can have unwind information for these functions.
Implementation
I _think_ what we'll want to do is move the location FPRs are preserved in up before stack locals, so they have small offsets from the function's stack frame base. See the diagram in @peterhuene's comment here and associated conversation for more.
Alternatives
Cranelift and its users don't have unwind information for some functions (currently witnessed as a panic, so users can't opt out for problematic functions)
ed: currently we miscompile these functions with or without unwind information. After https://github.com/bytecodealliance/wasmtime/pull/1216 lands, we'll produce working code, but not unwind information, for these. Specifically, unwind information for functions that would require these out-of-range FPR save offsets.
Wasmtime GitHub notifications bot (Apr 10 2020 at 20:31):iximeow labeled Issue #1475:
Cranelift should be able to compile x86 functions with stack frames requiring 240 bytes or more, when that also requires preserving a SIMD register. We've had to track an extension to the fastcall ABI that requires saving some, and due to Cranelift's choice in stack layout for these functions it's impossible to satisfy constraints required by Windows unwind information.
Benefit
Cranelift and its users can have unwind information for these functions.
Implementation
I _think_ what we'll want to do is move the location FPRs are preserved in up before stack locals, so they have small offsets from the function's stack frame base. See the diagram in @peterhuene's comment here and associated conversation for more.
Alternatives
Cranelift and its users don't have unwind information for some functions (currently witnessed as a panic, so users can't opt out for problematic functions)
ed: currently we miscompile these functions with or without unwind information. After https://github.com/bytecodealliance/wasmtime/pull/1216 lands, we'll produce working code, but not unwind information, for these. Specifically, unwind information for functions that would require these out-of-range FPR save offsets.
Wasmtime GitHub notifications bot (Apr 10 2020 at 20:31):iximeow labeled Issue #1475:
Cranelift should be able to compile x86 functions with stack frames requiring 240 bytes or more, when that also requires preserving a SIMD register. We've had to track an extension to the fastcall ABI that requires saving some, and due to Cranelift's choice in stack layout for these functions it's impossible to satisfy constraints required by Windows unwind information.
Benefit
Cranelift and its users can have unwind information for these functions.
Implementation
I _think_ what we'll want to do is move the location FPRs are preserved in up before stack locals, so they have small offsets from the function's stack frame base. See the diagram in @peterhuene's comment here and associated conversation for more.
Alternatives
Cranelift and its users don't have unwind information for some functions (currently witnessed as a panic, so users can't opt out for problematic functions)
ed: currently we miscompile these functions with or without unwind information. After https://github.com/bytecodealliance/wasmtime/pull/1216 lands, we'll produce working code, but not unwind information, for these. Specifically, unwind information for functions that would require these out-of-range FPR save offsets.
Wasmtime GitHub notifications bot (Apr 10 2020 at 20:31):github-actions[bot] commented on Issue #1475:
Subscribe to Label Action
cc @bnjbvr
<details>
This issue or pull request has been labeled: "cranelift"Thus the following users have been cc'd because of the following labels:
- bnjbvr: cranelift
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
Wasmtime GitHub notifications bot (May 20 2020 at 07:32):peterhuene assigned Issue #1475:
Cranelift should be able to compile x86 functions with stack frames requiring 240 bytes or more, when that also requires preserving a SIMD register. We've had to track an extension to the fastcall ABI that requires saving some, and due to Cranelift's choice in stack layout for these functions it's impossible to satisfy constraints required by Windows unwind information.
Benefit
Cranelift and its users can have unwind information for these functions.
Implementation
I _think_ what we'll want to do is move the location FPRs are preserved in up before stack locals, so they have small offsets from the function's stack frame base. See the diagram in @peterhuene's comment here and associated conversation for more.
Alternatives
Cranelift and its users don't have unwind information for some functions (currently witnessed as a panic, so users can't opt out for problematic functions)
ed: currently we miscompile these functions with or without unwind information. After https://github.com/bytecodealliance/wasmtime/pull/1216 lands, we'll produce working code, but not unwind information, for these. Specifically, unwind information for functions that would require these out-of-range FPR save offsets.
Wasmtime GitHub notifications bot (May 22 2020 at 19:06):peterhuene closed Issue #1475 (assigned to peterhuene):
Cranelift should be able to compile x86 functions with stack frames requiring 240 bytes or more, when that also requires preserving a SIMD register. We've had to track an extension to the fastcall ABI that requires saving some, and due to Cranelift's choice in stack layout for these functions it's impossible to satisfy constraints required by Windows unwind information.
Benefit
Cranelift and its users can have unwind information for these functions.
Implementation
I _think_ what we'll want to do is move the location FPRs are preserved in up before stack locals, so they have small offsets from the function's stack frame base. See the diagram in @peterhuene's comment here and associated conversation for more.
Alternatives
Cranelift and its users don't have unwind information for some functions (currently witnessed as a panic, so users can't opt out for problematic functions)
ed: currently we miscompile these functions with or without unwind information. After https://github.com/bytecodealliance/wasmtime/pull/1216 lands, we'll produce working code, but not unwind information, for these. Specifically, unwind information for functions that would require these out-of-range FPR save offsets.
Last updated: Nov 22 2024 at 16:03 UTC