Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x64: refactor REX-specific encoding machinery to its own module #2799

Merged
merged 1 commit into from
Apr 2, 2021

Conversation

abrown
Copy link
Contributor

@abrown abrown commented Apr 2, 2021

In preparation for adding new encoding modes to the x64 backend (e.g. VEX,
EVEX), this change moves all of the current instruction encoding functions to
encodings::rex. This refactor does not change any logic.

@abrown abrown requested review from bnjbvr and cfallin April 2, 2021 00:17
@@ -22,6 +22,7 @@ pub mod args;
mod emit;
#[cfg(test)]
mod emit_tests;
pub(crate) mod encoding;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about what visibility level is best for this module...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think crate-public is good for now. We should probably reconsider some of the other pub submodules, to be honest; IMHO we expose too much implementation already; but that's out-of-scope here :-)

},
machinst::{MachBuffer, MachInstEmitInfo},
};
use regalloc::{Reg, RegClass};
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a future change, I would like to:

  • factor out the external dependencies to this encoding code (I mean, why not? It would make it a bit easier to test and perhaps this code could be useful elsewhere?)
  • implement a few more abstractions like RexFlags to make this easier to work with (again, why not? Rust == "zero-cost abstractions," right? 😀)

Any thoughts for or against this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to both of these!

In particular to the first point: there is really an x86-64 assembler library begging to escape from this module -- it is "incomplete" in the sense that it only implements the instructions we actually need, but maybe it could be useful for other folks in the Rust world as well, eventually.

@@ -0,0 +1 @@
pub mod rex;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eventually other ways to encode instruction formats would get exposed here.

In preparation for adding new encoding modes to the x64 backend (e.g. VEX,
EVEX), this change moves all of the current instruction encoding functions to
`encodings::rex`. This refactor does not change any logic.
@github-actions github-actions bot added cranelift Issues related to the Cranelift code generator cranelift:area:x64 Issues related to x64 codegen labels Apr 2, 2021
Copy link
Member

@cfallin cfallin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

},
machinst::{MachBuffer, MachInstEmitInfo},
};
use regalloc::{Reg, RegClass};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to both of these!

In particular to the first point: there is really an x86-64 assembler library begging to escape from this module -- it is "incomplete" in the sense that it only implements the instructions we actually need, but maybe it could be useful for other folks in the Rust world as well, eventually.

@@ -22,6 +22,7 @@ pub mod args;
mod emit;
#[cfg(test)]
mod emit_tests;
pub(crate) mod encoding;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think crate-public is good for now. We should probably reconsider some of the other pub submodules, to be honest; IMHO we expose too much implementation already; but that's out-of-scope here :-)

@abrown abrown merged commit d32501c into bytecodealliance:main Apr 2, 2021
@abrown abrown deleted the inst-format branch April 2, 2021 18:17
@bnjbvr
Copy link
Member

bnjbvr commented Apr 6, 2021

crate-public is good for now.

+1 for this. I've tried to use it more generally, because making things generally public with pub (no pub(crate)) seems to make unused code invisible to rustc; in theory, external users could still use it, so it's considered live code. (And rustc doesn't seem to try to infer that things marked pub and buried in, but that are not accessible from the outside of the crate, are in fact equivalent to pub(crate).)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cranelift:area:x64 Issues related to x64 codegen cranelift Issues related to the Cranelift code generator
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants