Encoding SubType information for WASM GC types in wasm_encoder

[thesuhas]

Hi,

WASM GC introduces the notion of subtypes which is captured by wasmparser here. But, in the CoreTypeEncoder in wasm_encoder which is used to encode GC types into a binary, there is no obvious way to encode this subtype information.

One possible way is to use .subtype() to create a new subtype from scratch and encode it but I was wondering if there was a cleaner way to do this.

[alexcrichton]

Ah yes the intention is to use CoreTypeEncoder::subtype for the full generality of encoding types. Would Reencode::sub_type perhaps make this easier to call? That auto-converts from wasmparser-to-wasm-encoder

[thesuhas]

The issue with that is I'm maintaining my own IR with orca and I don't think the Reencode::sub_type would help as much. I think the best approach would be to convert my IR to wasm_encoder::sub_type

[thesuhas]

If I were to create my own subtype manually, would I have to preserve is_final and shared or would a default value suffice?

[alexcrichton]

It depends on what you're trying to do, but likely yes since you're transforming wasm you probably want to preserve is_final, shared, and supertype_idx.

[thesuhas]

I also noticed slightly ambiguous behaviour with the CoreTypeEncoder.subtype. When you encode an array that has no subtype and pass subtype as None using this, you still get (type $at (;2;) (sub (array i8))). But if you were to encode it using CoreTypeEncoder.array you get (type $at (;2;) (array i8)).
Why does .subtype() encode an empty subtype when the subtype is None?

[alexcrichton]

I think you're running into how the various properties of a type all render subtly different in the text format. I believe (sub (array i8)) means that is_final = false where (array i8) alone means is_final = true (although my memory could be wrong here too). You can also try out wasm-tools dump to get a more detailed output of all the bytes and fields

[thesuhas]

When it comes to encoding the Initializers in the Globals section, how would one encode array/struct initialisation instructions?
I don't see anything array/struct specific in wasm_encoder::ConstExpr.

[alexcrichton]

The next version will have a better helper but for now you'll have to use the "raw" constructor

[thesuhas]

Is there anyway to get the byte representation of an instruction? I don't see anything here

[alexcrichton]

You should be able to do what the helper is doing in the repo, using the Encode trait to encode into a Vec<u8>.

Put another way, this trait impl

[thesuhas]

Ah that makes sense, sorry about that!

[thesuhas]

I'm unable to determine if this is due to error on my part but I'm posting here for assistance.
This is the original wasm binary:

I notice that there is only one end statement which makes sense.

On using .raw() after using .encode() on

Instructions::RefFunc(f) => {
                    wasm_encoder::ConstExpr::ref_func(**f).encode(&mut bytes)
                }

and then encoding the global section in the module, I see that two end statements are getting encoded. One by .encode() and this is confirmed by the source code:

impl Encode for ConstExpr {
    fn encode(&self, sink: &mut Vec<u8>) {
        sink.extend(&self.bytes);
        Instruction::End.encode(sink);
    }
}

As a result, my wasm is failing validation. How can I fix this?

[alexcrichton]

When translating const expressions I think you'll probably want to go instruction-by-instruction and always use the raw constructor for wasm_encoder::ConstExpr. Each instruction would be translated one-at-a-time into a local Vec<u8> using Instruction::encode, and then after that's all complete you'd call ConstExpr::raw. I forget precisely how the End semantics work but I think you can omit the final End instruction when using ConstExpr::raw

[thesuhas]

I am not explicitly encoding the End instruction, wasm_encoder::ConstExpr::ref_func(**f).encode(&mut bytes) automatically seems to be adding End.
I'm currently encoding all the instructions in the initialization expression and encoding it into the same sink. Does that work?

[alexcrichton]

In the code you pasted above the case handling Instructions::RefFunc was converted to ConstExpr::encode. If that vector is then passed to ConstExpr::raw that's where the double-end is coming from (one from ConstExpr::encode, one from ConstExpr::raw). To solve that you'll want to use Instruction::encode in the per-instruction handling instead of ConstExpr::encode