Stream: git-wasmtime

Topic: wasmtime / PR #8122 cranelift: Remove srcloc from emit st...

Wasmtime GitHub notifications bot (Mar 13 2024 at 20:04):

jameysharp requested cfallin for a review on PR #8122.

Wasmtime GitHub notifications bot (Mar 13 2024 at 20:04):

jameysharp opened PR #8122 from jameysharp:no-trap-srcloc to bytecodealliance:main:

In #2426, @cfallin wrote:

[…] don't emit trap info unless an op can trap.

This end result was previously enacted by carrying a SourceLoc on
every load/store, which was somewhat cumbersome, and only indirectly
encoded metadata about a memory reference (can it trap) by its
presence or absence.

That PR changed both backends that existed at the time to check both the source location and the memory flags to determine whether a memory access could trap.

Then in #2685, @cfallin wrote:

Finally, while working out why trap records were not appearing, I had
noticed that isa::x64::emit_std_enc_mem() was only emitting heap-OOB
trap metadata for loads/stores when it had a srcloc. This PR ensures
that the metadata is emitted even when the srcloc is empty.

However that PR did not apply the same change to other backends. Since then, the pattern from #2426 has been copied to new backends.

I believe checking the source location has been unnecessary since #2426 and is now just a source of confusion at best, and possibly bugs at worst. So this PR makes all targets match the behavior of the x64 backend.

In addition, this pattern was the only reason why source locations were provided to any backend's emit state, so I'm removing that entirely. The cur_srcloc field has been unused on x64 since #2685.

This change is mostly straightforward, but there are two questionable changes in the riscv64 backend:

• The riscv64 backend had one use of this pattern for a BadConversionToInteger trap. All other uses on all backends were for HeapOutOfBounds traps. I suspect that was a copy-paste bug so I've removed it just like all the others.

• The riscv64 Inst::Atomic does not have a MemFlags field, so this means the HeapOutOfBounds trap metadata is added unconditionally for such instructions.

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Mar 13 2024 at 20:04):

jameysharp requested wasmtime-compiler-reviewers for a review on PR #8122.

Wasmtime GitHub notifications bot (Mar 13 2024 at 20:13):

cfallin submitted PR review:

LGTM -- thanks for finding this cleanup!

FWIW it should always be safe to emit extra trap records -- the "record exists and wasn't supposed to case" would matter only in that it could mask a separate bug, wherein the lowering generated a trap it wasn't supposed to, and turn it into a Wasm-level trap rather than a process crash. And that itself only if we use the instruction for internal logic separately from accesses that correspond to Wasm-level operators. So I think this is fine re: riscv64's Atomic MachInst.

Wasmtime GitHub notifications bot (Mar 13 2024 at 20:23):

jameysharp updated PR #8122.

Wasmtime GitHub notifications bot (Mar 13 2024 at 20:24):

jameysharp has enabled auto merge for PR #8122.

Wasmtime GitHub notifications bot (Mar 13 2024 at 21:15):

jameysharp merged PR #8122.

Last updated: Nov 22 2024 at 16:03 UTC