port(wasm): Add section emitters for type / import / function / global / export#1987
port(wasm): Add section emitters for type / import / function / global / export#1987lapla-cogito wants to merge 2 commits into
Conversation
lapla-cogito
force-pushed
the
section_emit
branch
from
72f4f94 to
85d88a5
Compare
lapla-cogito
changed the title
| uuid = { version = "1.3.0", features = ["v4"] } | ||
| wait-timeout = "0.2.0" | ||
| wait4 = "0.1.3" | ||
| wasm-encoder = "0.248.0" |
There was a problem hiding this comment.
I still have reservations about using wasm-encoder to do writing. Mostly because I don't see how we'll be able to make writing multi-threaded. If you're sure you want to go that route, it's fine, but I expect we won't be able to reach the same level of performance as we have for ELF.
There was a problem hiding this comment.
I think that, with the current wasm-encoder API, what is actually feasible is to generate the metadata on a single thread, generate raw instruction streams for the other sections in parallel across multiple threads, and then merge everything back on a single thread at the end to reconcile the indices. I'm not sure how much performance this would sacrifice, though.
There was a problem hiding this comment.
Is generating instruction streams computationally expensive? At least for ELF, most of the work is pretty much using memcpy to copy data around then applying a few relocations. With ELF, the destination of those copies is the actual output file and multiple threads are copying at once, with the destinations being non-overlapping areas of memory. If Wasm has to do a bunch of expensive computation to produce the stream, then that computation might dominate and it might not matter too much. But if like ELF, it's mostly copying data and applying a few relocations, then the part that merges everything back together is likely to be pretty slow, since it will need to perform an additional copy of pretty much the entire output file from a single thread.
| } | ||
|
|
||
| /// Imported globals in declaration order. Imports of other kinds are skipped. | ||
| pub(crate) fn global_imports(&self) -> Result<Vec<WasmGlobalImport<'data>>> { |
There was a problem hiding this comment.
It seems that there are lots of functions in this PR that aren't called
There was a problem hiding this comment.
This is intentional (the same pattern as wasm.rs, etc.). While much of the layout pipeline remains in TODO state, I'll use these functions after completing that.
There was a problem hiding this comment.
OK. How close are we to getting something that can run at least part of the way through the linking process and removing the #[allow(unused)]?
2 participants
Part of #1431