DynamoRIO / DynamoRIO/dynamorio
AArch64: Consider adding SIMD registers to OP_xx fall-back
- Dominant language
- C
- Stars
- 3.2k
- Forks
- 629
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 31
Description
The [OP_xx fall-back](https://github.com/DynamoRIO/dynamorio/blob/master/core/ir/aarch64/codec.c#L3444) correctly overestimates the set of general-purpose registers used by an instruction and will probably remain correct for most instructions that are added to the architecture (though see #4692 for an exception). It does not, however, take account of SIMD registers. For basic instruction mangling that does not matter: all that matters is discovering that the stolen register is (or might be) used and allocating a safe alternative. However, for clean call optimisation it is also necessary to know which SIMD registers might be used by the client code: currently, if a client FP or SIMD instruction is analysed as OP_xx then clean call optimisation is likely to be incorrect leading to corruption of guest SIMD registers. Adding a similar conservative estimate of which SIMD registers might be used by an unrecognised instruction could be helpful - though there may also be disadvantages that I haven't thought about.
Note that some SIMD instructions specify a register in the range V0-V15 using a 4-bit field at [19:16] instead of a 5-bit field at [20:16] so there are 5 possible locations for a register number in the encoding. Since some existing load/store instructions are not covered by the rule there is a definite possibility of some future instructions not being covered, but they could always be handled by adding them to the decoder (as suggested by #4692).
In the long term, all instructions should be added to the decoder, but in practice the decoder may at times be out-of-date so these fall-backs can be useful and should not be removed.
Contributor guide
Assessment
This issue has not been assessed yet.