| Age | Commit message (Collapse) | Author |
|---|
|
|
|
this request/suggestion comes from
[github](https://github.com/iximeow/yaxpeax-x86/issues/29)! thank you!
|
|
unlike every other function to test if a particular selector is picked
by prefixes, `Prefixes::cs` does not return bool, nor does it check the
currently-selected prefix. instead, it modifies the decoded `Prefixes`
to set the current prefix to `cs`.
this has been a bug all the way since 0.0.1 was released. the function
now does nothing, and is marked deprecated.
in a future 2.x release, the function will be changed to return `bool`
and be in-line with other segment selector-checking functions. in the
mean time, a new `Prefixes::selects_cs()` does the correct thing.
thank you to @meithecatte who pointed this out in
https://github.com/iximeow/yaxpeax-x86/issues/28!
|
|
|
|
|
|
the overwhelming majority of x86 instructions are either a single-byte
opcode or a single-byte opcode with a rex prefix. supporting these
specially means that we don't have to length-check on every byte or
go through the full decode loop while reading the most likely
instructions. this is a significant improvement on typical x86 streams,
but comes at a moderate penalty for crafted x86 instructions.
the penalty is still not very bad, as the fast path is exited in favor
of the full decode loop as soon as we see a non-rex prefix byte; this
adds maybe a dozen instructions to the slow path.
|
|
|
|
sharing vex/evex invalid prefix checks improves codegen a bit, but
ordering prefix checks by likeliest prefix first reduces time falling
through prefix handling arms. both together are a notable improvement in
throughput on typical x86 code.
bundled in here is some code motion to where `mem_size = 0` and
`operand_count = 2` are executed; this is because, at least on zen2 and
cascade lake parts, bunching all stores to the instruction together
caused small stalls getting into the decoder. spreading out stores seems
to mix these assignments with parts of code that was not using memory
anyway, and pipelines better.
|
|
cleanliness, but also slightly better codegen somehow?
|
|
the match compiled into some indirect branch awfulness!! no thank you
|
|
|
|
|
|
this includes a `Makefile` that exercises the various crate configs.
most annoyingly, several doc comments needed to grow
`#[cfg(feature="fmt")]` blocks so docs continue to build with that
feature enabled or disabled.
carved out a way to run exhaustive tests; they should be written as
`#[ignore]`, and then the makefile will run even ignored tests on the
expectation that this will run the exhaustive (but slower) suite.
exhaustive tests are not yet written. they'll probably involve spanning
4 byte sequences from 0 to 2^32-1.
|
|
Closes https://github.com/iximeow/yaxpeax-x86/issues/16
|
|
not only did the instruction have wrong data, but if displayed, the
formatter would panic.
|
|
in the process, fix 64-bit rex-byte limit, 32/16-bit mode mask reg limit
|
|
|
|
This makes generated docs refer to a type and show said type in the list of all structs rather than rustdoc showing gray text in return types.
quote doc references
|
|
|
|
|
|
|
|
this gets yaxpeax-x86 in no-inline configurations back to building as it
did before, but is quite a blunt hammer. it seems that extra calls to
`sink.record` trips the inlining thresholds for `read_with_annotation`,
and then its caller, and its caller, even when one of them is just a
delegation to its inner call.
this is particularly unfortunate because yaxpeax-x86 is now making a
decision about the inlining of a rather large function at the public
edge of its API, but these attributes match the inlining decisions that
LLVM was making before adding `DescriptionSink`. hopefully not too bad.
not sure how to handle this in the future.
|
|
|
|
|
|
|
|
even though NullSink is no-ops, it causes llvm to not inline this function, for a net perf reduction
|
|
|
|
|
|
|
|
these instructions had memory sizes reported for the operand, if it was
a memory operand, but for versions with non-memory operands the decoded
`Instruction` would imply that non memory access would happen at all.
now, decoded instructions in these cases will report a more useful
memory size.
|
|
and ip/flags
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
not that xop will ever be wanted, rip
|
|
|
|
this profiles slightly better? not entirely sure why...
|
|
|
|
|
