Stream: git-wasmtime

Topic: wasmtime / issue #1063 Cranelift: refactor CLIF instructi...

Wasmtime GitHub notifications bot (May 04 2022 at 20:27):

cfallin edited issue #1063:

I have a hunch that there is a decent amount of overhead from repetitive matches on dfg[inst]. We see a lot of

match pos.func.dfg[inst] {
    ir::InstructionData::StackLoad {
        ...
    } => ...,
    _ => panic!(...),
};

when we already know that inst is a stack_load.

This is required by the way that InstructionData is defined. We can't just pass a single instruction type into a function, we must pass an instance of the entire enum.

pub enum InstructionData {
    Unary {
        opcode: Opcode,
        arg: Value,
    },
    UnaryImm {
        opcode: Opcode,
        imm: ir::immediates::Imm64,
    },
    ...
}

I propose that we define a struct for each instruction type, as below:

struct UnaryImm {
    opcode: Opcode,
    imm: ir::immediates::Imm64,
}

enum InstructionData {
    Unary(Unary),
    UnaryImm(UnaryImm),
    ...
}

I think we should also go further, like bytecodealliance/wasmtime#1062 suggests and do this:

struct InstructionData {
    opcode: Opcode,
    args: ValueList,
    inst: Instruction,
}

enum Instruction {
    Unary(Unary),
    UnaryImm(UnaryImm),
    ...
}

Wasmtime GitHub notifications bot (May 04 2022 at 20:27):

cfallin labeled issue #1063:

I have a hunch that there is a decent amount of overhead from repetitive matches on dfg[inst]. We see a lot of

match pos.func.dfg[inst] {
    ir::InstructionData::StackLoad {
        ...
    } => ...,
    _ => panic!(...),
};

when we already know that inst is a stack_load.

This is required by the way that InstructionData is defined. We can't just pass a single instruction type into a function, we must pass an instance of the entire enum.

pub enum InstructionData {
    Unary {
        opcode: Opcode,
        arg: Value,
    },
    UnaryImm {
        opcode: Opcode,
        imm: ir::immediates::Imm64,
    },
    ...
}

I propose that we define a struct for each instruction type, as below:

struct UnaryImm {
    opcode: Opcode,
    imm: ir::immediates::Imm64,
}

enum InstructionData {
    Unary(Unary),
    UnaryImm(UnaryImm),
    ...
}

I think we should also go further, like bytecodealliance/wasmtime#1062 suggests and do this:

struct InstructionData {
    opcode: Opcode,
    args: ValueList,
    inst: Instruction,
}

enum Instruction {
    Unary(Unary),
    UnaryImm(UnaryImm),
    ...
}

Wasmtime GitHub notifications bot (Nov 06 2025 at 17:39):

fitzgen closed issue #1063:

I have a hunch that there is a decent amount of overhead from repetitive matches on dfg[inst]. We see a lot of

match pos.func.dfg[inst] {
    ir::InstructionData::StackLoad {
        ...
    } => ...,
    _ => panic!(...),
};

when we already know that inst is a stack_load.

This is required by the way that InstructionData is defined. We can't just pass a single instruction type into a function, we must pass an instance of the entire enum.

pub enum InstructionData {
    Unary {
        opcode: Opcode,
        arg: Value,
    },
    UnaryImm {
        opcode: Opcode,
        imm: ir::immediates::Imm64,
    },
    ...
}

I propose that we define a struct for each instruction type, as below:

struct UnaryImm {
    opcode: Opcode,
    imm: ir::immediates::Imm64,
}

enum InstructionData {
    Unary(Unary),
    UnaryImm(UnaryImm),
    ...
}

I think we should also go further, like bytecodealliance/wasmtime#1062 suggests and do this:

struct InstructionData {
    opcode: Opcode,
    args: ValueList,
    inst: Instruction,
}

enum Instruction {
    Unary(Unary),
    UnaryImm(UnaryImm),
    ...
}

Wasmtime GitHub notifications bot (Nov 06 2025 at 17:39):

fitzgen commented on issue #1063:

I think there are potentially interesting ways to refactor our instruction data, but what is proposed will not pack as nicely as what we have today, growing the size of instructions. Feel free to file new issues or PRs for specific improvements.

Last updated: Dec 13 2025 at 19:03 UTC