Sam Clegg

> what's wrong with making it both imported and exported? (as we did for wasi-threads) Nothing stops you from doing this but it seems redundant. As the embedder, if I...

It seems like a reasonable solution here would be to say "A module must either import *or* export something called `memory` which will be the memory that wasi API pointers...

> > As the embedder, if I am providing the memory and table as imports on the wasm file, why would I then want them to be re-expoted? > >...

Yes we were aware of this slightly strange fallout of enabled reference-types. For example we had (within Google) reports from folks using wamr that led to https://github.com/bytecodealliance/wasm-micro-runtime/pull/3726. Its a rather...

Also, just in case you were not aware, the linker has `--compress-relocations` flag that can be used to compress all these 5-byte LEBS. Also, any optimized build that goes through...

> wasm-ld wouldn't add the binary-encoding equivalent of (pagesize 64KiB) to every module it links together that uses the default page size I agree with this, but in this case...

I don't think the code size argument applies here since optimized binary should already be running though something like `wasm-opt` or built with `--compress-relocations`. Binaries that don't do this are...

I think adding a new single-byte relocation would be easier than trying to do something like compress-relocations but in reverse. `--compress-relocations` breaks debug info, so it only works on release...

I assume the idea would be to backport this change to the LLVM 19 branch?

> In general, it would also be a good idea for engines to support encoding changes introduced by new proposals, even if they are configured not to support the new...