There's a lot of trickery in this crate which expands to a lot of code, so in
addition to asserting that we find the right instruction, let's assert we find
a small function as well (as these should all be just one or so instructions
anyway).
This commit adds CI for a few more targets:
* i686-unknown-linux-gnu
* arm-unknown-linux-gnueabihf
* armv7-unknown-linux-gnueabihf
* aarch64-unknown-linux-gnu
The CI here is structured around using a Docker container to set up a test
environment and then QEMU is used to actually execute code from these platforms.
QEMU's emulation actually makes it so we can continue to just use `cargo test`,
as processes can be spawned from QEMU like `objdump` and files can be read (for
libbacktrace). Ends up being a relatively seamless experience!
Note that a number of intrinsics were disabled on i686 because they were failing
tests, and otherwise a few ARM touch-ups were made to get tests passing.
When comparing the assembly instructions against
the expected instruction, depending on the platform,
we might end up with `tzcntl != tzcnt`. This
commit truncates the instructions to the length
of the expected instruction, such that `tzcntl => tzcnt`
and the comparison succeeds.
This commit adds a procedural macro which can be used to test instruction
generation in a lightweight way. The intention is that all functions are
annotated with:
#[cfg_attr(test, assert_instr(maxps))]
fn foo(...) {
// ...
}
and then during `cargo test --release` it'll assert the function `foo` does
indeed generate the instruction `maxps`. This only activates tests in optimized
mode to avoid debug mode inefficiencies, and it uses a literal invocation of
`objdump` and some parsing to figure out what instructions are inside each
function. Finally it also uses the `backtrace` crate to figure out the symbol
name of the relevant function and hook that up to the output of `objdump`.
I added a few assertions in the `sse` module to get some feedback, but curious
what y'all think of this!
