Stream: git-wasmtime

Topic: wasmtime / Issue #1475 Cranelift: refactor Windows stack ...


view this post on Zulip 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.

view this post on Zulip 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.

view this post on Zulip 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.

view this post on Zulip 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:

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

view this post on Zulip 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.

view this post on Zulip 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: Dec 23 2024 at 12:05 UTC