Wasmtime GitHub notifications bot (Nov 10 2020 at 22:44): Wasmtime GitHub notifications bot (Nov 10 2020 at 22:44):cfallin opened PR #2388 from sourceloc to main:
In existing MachInst backends, many instructions -- any that can trap or
result in a relocation -- carrySourceLocvalues in order to propagate
the location-in-original-source to use to describe resulting traps or
relocation errors.This is quite tedious, and also error-prone: it is likely that the
necessary plumbing will be missed in some cases, and in any case, it's
unnecessarily verbose.This PR factors out the
SourceLochandling so that it is tracked
during emission as part of theEmitState, and plumbed through
automatically by the machine-independent framework. Instruction emission
code that directly emits trap or relocation records can query the
current location as necessary. Then we only need to ensure that memory
references and trap instructions, at their (one) emission point rather
than their (many) lowering/generation points, are wired up correctly.This does have the side-effect that some loads and stores that do not
correspond directly to user code's heap accesses will have unnecessary
but harmless trap metadata. For example, the load that fetches a code
offset from a jump table will have a 'heap out of bounds' trap record
attached to it; but because it is bounds-checked, and will never
actually trap if the lowering is correct, this should be harmless. The
simplicity improvement here seemed more worthwhile to me than plumbing
through a "corresponds to user-level load/store" bit, because the latter
is a bit complex when we allow for op merging.Closes #2290: though it does not implement a full "metadata" scheme as
described in that issue, this seems simpler overall.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
Wasmtime GitHub notifications bot (Nov 10 2020 at 22:44):cfallin requested abrown for a review on PR #2388.
Wasmtime GitHub notifications bot (Nov 10 2020 at 23:35):abrown submitted PR Review.
Wasmtime GitHub notifications bot (Nov 10 2020 at 23:35):abrown submitted PR Review.
Wasmtime GitHub notifications bot (Nov 10 2020 at 23:35):abrown created PR Review Comment:
sink.add_trap(srcloc, trap_info);This avoids unnecessary
let code = ...; possibly rename theUdffield totrap_code.
Wasmtime GitHub notifications bot (Nov 10 2020 at 23:47):cfallin updated PR #2388 from sourceloc to main:
In existing MachInst backends, many instructions -- any that can trap or
result in a relocation -- carrySourceLocvalues in order to propagate
the location-in-original-source to use to describe resulting traps or
relocation errors.This is quite tedious, and also error-prone: it is likely that the
necessary plumbing will be missed in some cases, and in any case, it's
unnecessarily verbose.This PR factors out the
SourceLochandling so that it is tracked
during emission as part of theEmitState, and plumbed through
automatically by the machine-independent framework. Instruction emission
code that directly emits trap or relocation records can query the
current location as necessary. Then we only need to ensure that memory
references and trap instructions, at their (one) emission point rather
than their (many) lowering/generation points, are wired up correctly.This does have the side-effect that some loads and stores that do not
correspond directly to user code's heap accesses will have unnecessary
but harmless trap metadata. For example, the load that fetches a code
offset from a jump table will have a 'heap out of bounds' trap record
attached to it; but because it is bounds-checked, and will never
actually trap if the lowering is correct, this should be harmless. The
simplicity improvement here seemed more worthwhile to me than plumbing
through a "corresponds to user-level load/store" bit, because the latter
is a bit complex when we allow for op merging.Closes #2290: though it does not implement a full "metadata" scheme as
described in that issue, this seems simpler overall.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
Wasmtime GitHub notifications bot (Nov 10 2020 at 23:47):cfallin submitted PR Review.
Wasmtime GitHub notifications bot (Nov 10 2020 at 23:47):cfallin created PR Review Comment:
Good point, thanks!
Wasmtime GitHub notifications bot (Nov 11 2020 at 01:05):cfallin merged PR #2388.
Last updated: Dec 23 2024 at 12:05 UTC