jameysharp requested abrown for a review on PR #8134.
jameysharp opened PR #8134 from jameysharp:memflags-trapcode
to bytecodealliance:main
:
Ideally we'd allow the frontend to specify what trap code a memory access instruction can produce, but we don't have room to store that information.
Instead, I'm adding additional meaning to the
table
andheap
memflags. Besides being used in alias analysis, these flags now also indicate whether the instruction should produce a trap code of TableOutOfBounds or HeapOutOfBounds, respectively.In the Cranelift weekly meeting we discussed that it would be nice to assert that either
table
orheap
is set when the trap-code is requested, but I don't know if all users of the instruction encodings (such as cg-clif or Winch) set those flags, so I've chosen to default to the old behavior if none of the alias-analysis flags are set.Currently, memory accesses with the
table
flag set always havenotrap
set as well, so the TableOutOfBounds case is never hit, but I wanted to separate this change out from the cranelift-wasm changes which will use it.
jameysharp requested wasmtime-compiler-reviewers for a review on PR #8134.
@cfallin, @elliottt: do you want to review this instead? I am not as familiar with these trapping bits as I should be.
cfallin requested cfallin for a review on PR #8134.
cfallin submitted PR review.
cfallin submitted PR review.
cfallin created PR review comment:
I like the idea of this riding along with
MemFlags
-- it seems the most appropriate place to put it. However I'm not so sure about overloading the meaning of the alias-analysis bits; that feels like a future bug waiting to happen. Or at the very least, ties together a correctness-bearing concern with the particular implementation details of this version of an optimization pass. (E.g., what if we have a more detailed alias analysis in the future?)We have a
u16
for bitflags and only 9 flags defined currently; would you mind adding another two fortable_trap
andheap_trap
?
jameysharp updated PR #8134.
jameysharp submitted PR review.
jameysharp created PR review comment:
That concern makes sense, although I don't think we should define both
table_trap
andheap_trap
as separate bits, because then what trap code should we return if neither is set? So instead I've introduced a singletabletrap
bit, and if it's not set, the trap code isheap_oob
as usual.
cfallin submitted PR review.
cfallin created PR review comment:
OK, yep, that seems reasonable -- thanks!
cfallin submitted PR review:
LGTM!
cfallin has enabled auto merge for PR #8134.
cfallin merged PR #8134.
Last updated: Dec 23 2024 at 12:05 UTC