abrown opened Issue #1342:
<!-- Please try to describe precisely what you would like to do in
Cranelift/Wasmtime and/or expect from it. You can answer the questions below if
they're relevant and delete this text before submitting. Thanks for opening an
issue! -->Feature
Disallow
infer_rex
andw
on the same encoding template<!-- What is the feature or code improvement you would like to do in
Cranelift/Wasmtime? -->Benefit
In cranelift x86 encodings, it seems unintuitive that we can specialize
Template
s with bothinfer_rex
andw
: ifw
is specified, the REX.W bit must be set so a REX prefix is required. In this case, it seems more clear to force ourselves to writerex().w()
--it's more explicit and shows more clearly what cranelift will emit.
<!-- What is the value of adding this in Cranelift/Wasmtime? -->Implementation
<!-- Do you have an implementation plan, and/or ideas for data structures or
algorithms to use? -->
- In the
RecipePrefixKind::InferRex
arm ofTemplate::build
, add an assertion to prevent the use ofw()
. E.g.assert!(!self.w_bit, "No need to infer REX prefix when REX.W is specified, use rex() instead")
- Optionally remove the runtime check for the REX.W bit in
needs_rex
(binemit.rs
) and the size calculator functions inenc_tables.rs
; this probably has some negligible runtime improvement and could be replaced by a comment indicating that the REX.W check has been performed statically.Alternatives
<!-- Have you considered alternative implementations? If so, how are they
better or worse than your proposal? -->
Do nothing.
abrown edited Issue #1342:
<!-- Please try to describe precisely what you would like to do in
Cranelift/Wasmtime and/or expect from it. You can answer the questions below if
they're relevant and delete this text before submitting. Thanks for opening an
issue! -->Feature
Disallow
infer_rex
andw
on the same encoding template<!-- What is the feature or code improvement you would like to do in
Cranelift/Wasmtime? -->Benefit
In cranelift x86 encodings, it seems unintuitive that we can specialize
Template
s with bothinfer_rex
andw
: ifw
is specified, the REX.W bit must be set so a REX prefix is alway required--no need to infer it. In this case, it seems more clear to force ourselves to writerex().w()
--it's more explicit and shows more clearly what cranelift will emit.
<!-- What is the value of adding this in Cranelift/Wasmtime? -->Implementation
<!-- Do you have an implementation plan, and/or ideas for data structures or
algorithms to use? -->
- In the
RecipePrefixKind::InferRex
arm ofTemplate::build
, add an assertion to prevent the use ofw()
. E.g.assert!(!self.w_bit, "No need to infer REX prefix when REX.W is specified, use rex() instead")
- Optionally remove the runtime check for the REX.W bit in
needs_rex
(binemit.rs
) and the size calculator functions inenc_tables.rs
; this probably has some negligible runtime improvement and could be replaced by a comment indicating that the REX.W check has been performed statically.Alternatives
<!-- Have you considered alternative implementations? If so, how are they
better or worse than your proposal? -->
Do nothing.
abrown labeled Issue #1342:
<!-- Please try to describe precisely what you would like to do in
Cranelift/Wasmtime and/or expect from it. You can answer the questions below if
they're relevant and delete this text before submitting. Thanks for opening an
issue! -->Feature
Disallow
infer_rex
andw
on the same encoding template<!-- What is the feature or code improvement you would like to do in
Cranelift/Wasmtime? -->Benefit
In cranelift x86 encodings, it seems unintuitive that we can specialize
Template
s with bothinfer_rex
andw
: ifw
is specified, the REX.W bit must be set so a REX prefix is alway required--no need to infer it. In this case, it seems more clear to force ourselves to writerex().w()
--it's more explicit and shows more clearly what cranelift will emit.
<!-- What is the value of adding this in Cranelift/Wasmtime? -->Implementation
<!-- Do you have an implementation plan, and/or ideas for data structures or
algorithms to use? -->
- In the
RecipePrefixKind::InferRex
arm ofTemplate::build
, add an assertion to prevent the use ofw()
. E.g.assert!(!self.w_bit, "No need to infer REX prefix when REX.W is specified, use rex() instead")
- Optionally remove the runtime check for the REX.W bit in
needs_rex
(binemit.rs
) and the size calculator functions inenc_tables.rs
; this probably has some negligible runtime improvement and could be replaced by a comment indicating that the REX.W check has been performed statically.Alternatives
<!-- Have you considered alternative implementations? If so, how are they
better or worse than your proposal? -->
Do nothing.
abrown closed Issue #1342:
<!-- Please try to describe precisely what you would like to do in
Cranelift/Wasmtime and/or expect from it. You can answer the questions below if
they're relevant and delete this text before submitting. Thanks for opening an
issue! -->Feature
Disallow
infer_rex
andw
on the same encoding template<!-- What is the feature or code improvement you would like to do in
Cranelift/Wasmtime? -->Benefit
In cranelift x86 encodings, it seems unintuitive that we can specialize
Template
s with bothinfer_rex
andw
: ifw
is specified, the REX.W bit must be set so a REX prefix is alway required--no need to infer it. In this case, it seems more clear to force ourselves to writerex().w()
--it's more explicit and shows more clearly what cranelift will emit.
<!-- What is the value of adding this in Cranelift/Wasmtime? -->Implementation
<!-- Do you have an implementation plan, and/or ideas for data structures or
algorithms to use? -->
- In the
RecipePrefixKind::InferRex
arm ofTemplate::build
, add an assertion to prevent the use ofw()
. E.g.assert!(!self.w_bit, "No need to infer REX prefix when REX.W is specified, use rex() instead")
- Optionally remove the runtime check for the REX.W bit in
needs_rex
(binemit.rs
) and the size calculator functions inenc_tables.rs
; this probably has some negligible runtime improvement and could be replaced by a comment indicating that the REX.W check has been performed statically.Alternatives
<!-- Have you considered alternative implementations? If so, how are they
better or worse than your proposal? -->
Do nothing.
Last updated: Nov 22 2024 at 16:03 UTC