Stream: git-wasmtime

Topic: wasmtime / PR #1960 peepmatic: Be generic over the IR we ...

view this post on Zulip Wasmtime GitHub notifications bot (Jul 01 2020 at 22:41):

fitzgen opened PR #1960 from peepmatic-generic-over-ir to main:

This lets us avoid the cost of cranelift_codegen::ir::Opcode to
peepmatic_runtime::Operator conversion overhead, and paves the way for
allowing Peepmatic to support non-clif optimizations (e.g. vcode optimizations).

Rather than defining our own peepmatic::Operator type like we used to, now the
whole peepmatic crate is effectively generic over a TOperator type
parameter. For the Cranelift integration, we use cranelift_codegen::ir::Opcode
as the concrete type for our TOperator type parameter. For testing, we also
define a TestOperator type, so that we can test Peepmatic code without
building all of Cranelift, and we can keep them somewhat isolated from each
other.

The methods that peepmatic::Operator had are now translated into trait bounds
on the TOperator type. These traits need to be shared between all of
peepmatic, peepmatic-runtime, and cranelift-codegen's Peepmatic
integration. Therefore, these new traits live in a new crate:
peepmatic-traits. This crate acts as a header file of sorts for shared
trait/type/macro definitions.

Additionally, the peepmatic-runtime crate no longer depends on the
peepmatic-macro procedural macro crate, which should lead to faster build
times for Cranelift when it is using pre-built peephole optimizers.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 01 2020 at 22:41):

fitzgen requested sunfishcode for a review on PR #1960.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 01 2020 at 22:44):

fitzgen updated PR #1960 from peepmatic-generic-over-ir to main:

This lets us avoid the cost of cranelift_codegen::ir::Opcode to
peepmatic_runtime::Operator conversion overhead, and paves the way for
allowing Peepmatic to support non-clif optimizations (e.g. vcode optimizations).

Rather than defining our own peepmatic::Operator type like we used to, now the
whole peepmatic crate is effectively generic over a TOperator type
parameter. For the Cranelift integration, we use cranelift_codegen::ir::Opcode
as the concrete type for our TOperator type parameter. For testing, we also
define a TestOperator type, so that we can test Peepmatic code without
building all of Cranelift, and we can keep them somewhat isolated from each
other.

The methods that peepmatic::Operator had are now translated into trait bounds
on the TOperator type. These traits need to be shared between all of
peepmatic, peepmatic-runtime, and cranelift-codegen's Peepmatic
integration. Therefore, these new traits live in a new crate:
peepmatic-traits. This crate acts as a header file of sorts for shared
trait/type/macro definitions.

Additionally, the peepmatic-runtime crate no longer depends on the
peepmatic-macro procedural macro crate, which should lead to faster build
times for Cranelift when it is using pre-built peephole optimizers.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 01 2020 at 23:43):

fitzgen updated PR #1960 from peepmatic-generic-over-ir to main:

This lets us avoid the cost of cranelift_codegen::ir::Opcode to
peepmatic_runtime::Operator conversion overhead, and paves the way for
allowing Peepmatic to support non-clif optimizations (e.g. vcode optimizations).

Rather than defining our own peepmatic::Operator type like we used to, now the
whole peepmatic crate is effectively generic over a TOperator type
parameter. For the Cranelift integration, we use cranelift_codegen::ir::Opcode
as the concrete type for our TOperator type parameter. For testing, we also
define a TestOperator type, so that we can test Peepmatic code without
building all of Cranelift, and we can keep them somewhat isolated from each
other.

The methods that peepmatic::Operator had are now translated into trait bounds
on the TOperator type. These traits need to be shared between all of
peepmatic, peepmatic-runtime, and cranelift-codegen's Peepmatic
integration. Therefore, these new traits live in a new crate:
peepmatic-traits. This crate acts as a header file of sorts for shared
trait/type/macro definitions.

Additionally, the peepmatic-runtime crate no longer depends on the
peepmatic-macro procedural macro crate, which should lead to faster build
times for Cranelift when it is using pre-built peephole optimizers.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 17 2020 at 19:35):

sunfishcode submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 17 2020 at 19:35):

sunfishcode created PR Review Comment:

Should this dependency also have optional = true, so that it isn't pulled in if peepmatic isn't enabled?

view this post on Zulip Wasmtime GitHub notifications bot (Jul 17 2020 at 19:35):

sunfishcode submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 17 2020 at 21:05):

fitzgen submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 17 2020 at 21:05):

fitzgen created PR Review Comment:

Good catch!

view this post on Zulip Wasmtime GitHub notifications bot (Jul 17 2020 at 21:30):

fitzgen updated PR #1960 from peepmatic-generic-over-ir to main:

This lets us avoid the cost of cranelift_codegen::ir::Opcode to
peepmatic_runtime::Operator conversion overhead, and paves the way for
allowing Peepmatic to support non-clif optimizations (e.g. vcode optimizations).

Rather than defining our own peepmatic::Operator type like we used to, now the
whole peepmatic crate is effectively generic over a TOperator type
parameter. For the Cranelift integration, we use cranelift_codegen::ir::Opcode
as the concrete type for our TOperator type parameter. For testing, we also
define a TestOperator type, so that we can test Peepmatic code without
building all of Cranelift, and we can keep them somewhat isolated from each
other.

The methods that peepmatic::Operator had are now translated into trait bounds
on the TOperator type. These traits need to be shared between all of
peepmatic, peepmatic-runtime, and cranelift-codegen's Peepmatic
integration. Therefore, these new traits live in a new crate:
peepmatic-traits. This crate acts as a header file of sorts for shared
trait/type/macro definitions.

Additionally, the peepmatic-runtime crate no longer depends on the
peepmatic-macro procedural macro crate, which should lead to faster build
times for Cranelift when it is using pre-built peephole optimizers.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 17 2020 at 21:32):

fitzgen updated PR #1960 from peepmatic-generic-over-ir to main:

This lets us avoid the cost of cranelift_codegen::ir::Opcode to
peepmatic_runtime::Operator conversion overhead, and paves the way for
allowing Peepmatic to support non-clif optimizations (e.g. vcode optimizations).

Rather than defining our own peepmatic::Operator type like we used to, now the
whole peepmatic crate is effectively generic over a TOperator type
parameter. For the Cranelift integration, we use cranelift_codegen::ir::Opcode
as the concrete type for our TOperator type parameter. For testing, we also
define a TestOperator type, so that we can test Peepmatic code without
building all of Cranelift, and we can keep them somewhat isolated from each
other.

The methods that peepmatic::Operator had are now translated into trait bounds
on the TOperator type. These traits need to be shared between all of
peepmatic, peepmatic-runtime, and cranelift-codegen's Peepmatic
integration. Therefore, these new traits live in a new crate:
peepmatic-traits. This crate acts as a header file of sorts for shared
trait/type/macro definitions.

Additionally, the peepmatic-runtime crate no longer depends on the
peepmatic-macro procedural macro crate, which should lead to faster build
times for Cranelift when it is using pre-built peephole optimizers.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 17 2020 at 21:41):

fitzgen updated PR #1960 from peepmatic-generic-over-ir to main:

This lets us avoid the cost of cranelift_codegen::ir::Opcode to
peepmatic_runtime::Operator conversion overhead, and paves the way for
allowing Peepmatic to support non-clif optimizations (e.g. vcode optimizations).

Rather than defining our own peepmatic::Operator type like we used to, now the
whole peepmatic crate is effectively generic over a TOperator type
parameter. For the Cranelift integration, we use cranelift_codegen::ir::Opcode
as the concrete type for our TOperator type parameter. For testing, we also
define a TestOperator type, so that we can test Peepmatic code without
building all of Cranelift, and we can keep them somewhat isolated from each
other.

The methods that peepmatic::Operator had are now translated into trait bounds
on the TOperator type. These traits need to be shared between all of
peepmatic, peepmatic-runtime, and cranelift-codegen's Peepmatic
integration. Therefore, these new traits live in a new crate:
peepmatic-traits. This crate acts as a header file of sorts for shared
trait/type/macro definitions.

Additionally, the peepmatic-runtime crate no longer depends on the
peepmatic-macro procedural macro crate, which should lead to faster build
times for Cranelift when it is using pre-built peephole optimizers.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 17 2020 at 21:52):

fitzgen updated PR #1960 from peepmatic-generic-over-ir to main:

This lets us avoid the cost of cranelift_codegen::ir::Opcode to
peepmatic_runtime::Operator conversion overhead, and paves the way for
allowing Peepmatic to support non-clif optimizations (e.g. vcode optimizations).

Rather than defining our own peepmatic::Operator type like we used to, now the
whole peepmatic crate is effectively generic over a TOperator type
parameter. For the Cranelift integration, we use cranelift_codegen::ir::Opcode
as the concrete type for our TOperator type parameter. For testing, we also
define a TestOperator type, so that we can test Peepmatic code without
building all of Cranelift, and we can keep them somewhat isolated from each
other.

The methods that peepmatic::Operator had are now translated into trait bounds
on the TOperator type. These traits need to be shared between all of
peepmatic, peepmatic-runtime, and cranelift-codegen's Peepmatic
integration. Therefore, these new traits live in a new crate:
peepmatic-traits. This crate acts as a header file of sorts for shared
trait/type/macro definitions.

Additionally, the peepmatic-runtime crate no longer depends on the
peepmatic-macro procedural macro crate, which should lead to faster build
times for Cranelift when it is using pre-built peephole optimizers.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 17 2020 at 22:14):

fitzgen updated PR #1960 from peepmatic-generic-over-ir to main:

This lets us avoid the cost of cranelift_codegen::ir::Opcode to
peepmatic_runtime::Operator conversion overhead, and paves the way for
allowing Peepmatic to support non-clif optimizations (e.g. vcode optimizations).

Rather than defining our own peepmatic::Operator type like we used to, now the
whole peepmatic crate is effectively generic over a TOperator type
parameter. For the Cranelift integration, we use cranelift_codegen::ir::Opcode
as the concrete type for our TOperator type parameter. For testing, we also
define a TestOperator type, so that we can test Peepmatic code without
building all of Cranelift, and we can keep them somewhat isolated from each
other.

The methods that peepmatic::Operator had are now translated into trait bounds
on the TOperator type. These traits need to be shared between all of
peepmatic, peepmatic-runtime, and cranelift-codegen's Peepmatic
integration. Therefore, these new traits live in a new crate:
peepmatic-traits. This crate acts as a header file of sorts for shared
trait/type/macro definitions.

Additionally, the peepmatic-runtime crate no longer depends on the
peepmatic-macro procedural macro crate, which should lead to faster build
times for Cranelift when it is using pre-built peephole optimizers.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 17 2020 at 23:16):

fitzgen updated PR #1960 from peepmatic-generic-over-ir to main:

This lets us avoid the cost of cranelift_codegen::ir::Opcode to
peepmatic_runtime::Operator conversion overhead, and paves the way for
allowing Peepmatic to support non-clif optimizations (e.g. vcode optimizations).

Rather than defining our own peepmatic::Operator type like we used to, now the
whole peepmatic crate is effectively generic over a TOperator type
parameter. For the Cranelift integration, we use cranelift_codegen::ir::Opcode
as the concrete type for our TOperator type parameter. For testing, we also
define a TestOperator type, so that we can test Peepmatic code without
building all of Cranelift, and we can keep them somewhat isolated from each
other.

The methods that peepmatic::Operator had are now translated into trait bounds
on the TOperator type. These traits need to be shared between all of
peepmatic, peepmatic-runtime, and cranelift-codegen's Peepmatic
integration. Therefore, these new traits live in a new crate:
peepmatic-traits. This crate acts as a header file of sorts for shared
trait/type/macro definitions.

Additionally, the peepmatic-runtime crate no longer depends on the
peepmatic-macro procedural macro crate, which should lead to faster build
times for Cranelift when it is using pre-built peephole optimizers.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 18 2020 at 00:05):

fitzgen merged PR #1960.

Last updated: Dec 06 2025 at 06:05 UTC