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
wholepeepmatic
crate is effectively generic over aTOperator
type
parameter. For the Cranelift integration, we usecranelift_codegen::ir::Opcode
as the concrete type for ourTOperator
type parameter. For testing, we also
define aTestOperator
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 theTOperator
type. These traits need to be shared between all of
peepmatic
,peepmatic-runtime
, andcranelift-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.
fitzgen requested sunfishcode for a review on PR #1960.
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
wholepeepmatic
crate is effectively generic over aTOperator
type
parameter. For the Cranelift integration, we usecranelift_codegen::ir::Opcode
as the concrete type for ourTOperator
type parameter. For testing, we also
define aTestOperator
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 theTOperator
type. These traits need to be shared between all of
peepmatic
,peepmatic-runtime
, andcranelift-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.
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
wholepeepmatic
crate is effectively generic over aTOperator
type
parameter. For the Cranelift integration, we usecranelift_codegen::ir::Opcode
as the concrete type for ourTOperator
type parameter. For testing, we also
define aTestOperator
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 theTOperator
type. These traits need to be shared between all of
peepmatic
,peepmatic-runtime
, andcranelift-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.
sunfishcode submitted PR Review.
sunfishcode created PR Review Comment:
Should this dependency also have
optional = true
, so that it isn't pulled in if peepmatic isn't enabled?
sunfishcode submitted PR Review.
fitzgen submitted PR Review.
fitzgen created PR Review Comment:
Good catch!
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
wholepeepmatic
crate is effectively generic over aTOperator
type
parameter. For the Cranelift integration, we usecranelift_codegen::ir::Opcode
as the concrete type for ourTOperator
type parameter. For testing, we also
define aTestOperator
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 theTOperator
type. These traits need to be shared between all of
peepmatic
,peepmatic-runtime
, andcranelift-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.
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
wholepeepmatic
crate is effectively generic over aTOperator
type
parameter. For the Cranelift integration, we usecranelift_codegen::ir::Opcode
as the concrete type for ourTOperator
type parameter. For testing, we also
define aTestOperator
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 theTOperator
type. These traits need to be shared between all of
peepmatic
,peepmatic-runtime
, andcranelift-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.
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
wholepeepmatic
crate is effectively generic over aTOperator
type
parameter. For the Cranelift integration, we usecranelift_codegen::ir::Opcode
as the concrete type for ourTOperator
type parameter. For testing, we also
define aTestOperator
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 theTOperator
type. These traits need to be shared between all of
peepmatic
,peepmatic-runtime
, andcranelift-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.
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
wholepeepmatic
crate is effectively generic over aTOperator
type
parameter. For the Cranelift integration, we usecranelift_codegen::ir::Opcode
as the concrete type for ourTOperator
type parameter. For testing, we also
define aTestOperator
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 theTOperator
type. These traits need to be shared between all of
peepmatic
,peepmatic-runtime
, andcranelift-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.
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
wholepeepmatic
crate is effectively generic over aTOperator
type
parameter. For the Cranelift integration, we usecranelift_codegen::ir::Opcode
as the concrete type for ourTOperator
type parameter. For testing, we also
define aTestOperator
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 theTOperator
type. These traits need to be shared between all of
peepmatic
,peepmatic-runtime
, andcranelift-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.
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
wholepeepmatic
crate is effectively generic over aTOperator
type
parameter. For the Cranelift integration, we usecranelift_codegen::ir::Opcode
as the concrete type for ourTOperator
type parameter. For testing, we also
define aTestOperator
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 theTOperator
type. These traits need to be shared between all of
peepmatic
,peepmatic-runtime
, andcranelift-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.
fitzgen merged PR #1960.
Last updated: Dec 23 2024 at 13:07 UTC