Stream: git-wasmtime

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


view this post on Zulip 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),
    ...
}

view this post on Zulip 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),
    ...
}


Last updated: Dec 23 2024 at 12:05 UTC