Rik Huijzer (Jan 07 2025 at 11:57): Rik Huijzer (Jan 07 2025 at 11:57):Maybe a bit of a dumb question but say I’m making a compiler that compiles to WebAssembly, would there be reasons to target wasm binary format directly instead of wat? I’m thinking about targeting wat and letting Cranelift handle the rest, but would wat be in general a good idea? I would like to avoid the Cranelift IR since I’m already using the MLIR IR.
Rik Huijzer (Jan 07 2025 at 11:58):By the way complements for the wasmtime team. The wasmtime API was easy to use and I’m very impressed with the final binary size when precompiling to wasm and only using the runtime
Rik Huijzer (Jan 07 2025 at 15:11):I think I see now. I should probably use the cranelift frontend
Rik Huijzer (Jan 08 2025 at 11:37):Hmm no seems not. Cranelift is to compile wasm to native. I’m looking to compile my IR to wasm (without LLVM). @Alex Crichton could I target data types from the wast crate? The readme doesn’t specify that case but it could be reasonable I think?
Joel Dice (Jan 08 2025 at 14:45):Have you looked at wasm_encoder? That's the usual choice when generating Wasm code in Rust. It won't do any optimization for you, but you could follow up by running the output through e.g. wasm-opt.
Rik Huijzer (Jan 08 2025 at 14:56):Thanks Joel! I hadn’t found that yet no. Exactly what I was looking for
Alex Crichton (Jan 08 2025 at 15:27):I'd agree with Joel yeah that wast is probably not the best choice for a compiler, but wasm-encoder should work well. Although the text format has a lot of "sugar" where you don't have to worry about things that you'll have to worry about with wasm-encoder, so I'd recommend watching out for that
Rik Huijzer (Jan 08 2025 at 16:18):Nice! I was wondering about that. Thanks Alex I’ll keep it in mind
Last updated: Jan 24 2025 at 00:11 UTC