Stream: git-wasmtime

Topic: wasmtime / issue #5291 Remove null-check in generated cod...

Wasmtime GitHub notifications bot (Nov 17 2022 at 16:05):

alexcrichton labeled issue #5291:

Currently when translating the call_indirect instruction Wasmtime will insert a null-check to ensure that we're not calling a null function pointer. Because our representation of a null function pointer is literally a null pointer, however, I think we can actually skip this check entirely due to the next instruction being guaranteed to segfault if it's actually a null pointer.

I don't think this is necessarily as easy as simply removing the null pointer check, however, since I think the load needs to at least somehow be annotated with the proper trap code and probably "this can segfault", which I'm not precisely sure how to do. This could be a nice way to clean up the generated code for call_indirect slightly thought which is already somewhat large I believe.

Wasmtime GitHub notifications bot (Nov 17 2022 at 16:05):

alexcrichton labeled issue #5291:

Currently when translating the call_indirect instruction Wasmtime will insert a null-check to ensure that we're not calling a null function pointer. Because our representation of a null function pointer is literally a null pointer, however, I think we can actually skip this check entirely due to the next instruction being guaranteed to segfault if it's actually a null pointer.

I don't think this is necessarily as easy as simply removing the null pointer check, however, since I think the load needs to at least somehow be annotated with the proper trap code and probably "this can segfault", which I'm not precisely sure how to do. This could be a nice way to clean up the generated code for call_indirect slightly thought which is already somewhat large I believe.

Wasmtime GitHub notifications bot (Nov 17 2022 at 16:05):

alexcrichton opened issue #5291:

Currently when translating the call_indirect instruction Wasmtime will insert a null-check to ensure that we're not calling a null function pointer. Because our representation of a null function pointer is literally a null pointer, however, I think we can actually skip this check entirely due to the next instruction being guaranteed to segfault if it's actually a null pointer.

I don't think this is necessarily as easy as simply removing the null pointer check, however, since I think the load needs to at least somehow be annotated with the proper trap code and probably "this can segfault", which I'm not precisely sure how to do. This could be a nice way to clean up the generated code for call_indirect slightly thought which is already somewhat large I believe.

Wasmtime GitHub notifications bot (Nov 17 2022 at 19:52):

fitzgen commented on issue #5291:

Not sure if we have a bit free in MemFlags but if so, we could have a bit that means "the trap code should be indirect-call-to-null-rather-than-heap-out-of-bounds".

Wasmtime GitHub notifications bot (Nov 17 2022 at 20:33):

jameysharp commented on issue #5291:

MemFlags is a u8 and already has 8 flags defined.

But several flags are mutually exclusive, so we could encode them more concisely. In particular, the Heap, Table, and Vmctx flags represent four states (counting "other") which could be encoded in two bits instead of three.

Wasmtime GitHub notifications bot (Mar 17 2024 at 16:56):

jameysharp commented on issue #5291:

At some point we widened MemFlags to 16 bits, and in #8134 we added a MemFlags bit for indicating another trap-code, so we could do something similar for this case too.

That means there are four cases (can't trap, or could trap with one of three different trap codes). I would kind of like to start packing these enumeration flags into groups of bits, so that this wouldn't change how many bits we're using in MemFlags.

It wouldn't be the end of the world to add another bit for this though.

Wasmtime GitHub notifications bot (Mar 18 2024 at 19:55):

alexcrichton closed issue #5291:

Currently when translating the call_indirect instruction Wasmtime will insert a null-check to ensure that we're not calling a null function pointer. Because our representation of a null function pointer is literally a null pointer, however, I think we can actually skip this check entirely due to the next instruction being guaranteed to segfault if it's actually a null pointer.

I don't think this is necessarily as easy as simply removing the null pointer check, however, since I think the load needs to at least somehow be annotated with the proper trap code and probably "this can segfault", which I'm not precisely sure how to do. This could be a nice way to clean up the generated code for call_indirect slightly thought which is already somewhat large I believe.

Last updated: Oct 23 2024 at 20:03 UTC