RFR: 8257137: Revise smov and umov in aarch64 assembler
Hao Sun
github.com+16932759+shqking at openjdk.java.net
Thu Dec 31 06:50:55 UTC 2020
On Thu, 3 Dec 2020 03:26:00 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> wrote:
> 1. Both smov and umov lack of checking the register type validity.
> Register type must be 'B', 'H' or 'S' for smov [1].
> Register type can NOT be 'Q' for umov [2].
> Such checks are added.
>
> 2. smov and umov have different explanations on 'Q' field, i.e. bit 30
> of the insturction, but current assembler implementation mixed it up.
> For umov, 'Q' field can only be set when register type 'D' is given
> [2]. However, this field of smov must be set for register type 'S'
> [1], that is, 'Q' field can be optional for register type 'B' or 'H'.
>
> Current implementation only took the umov scenario into account. As a
> result, runtime error ILL_ILLOPN would occur if 'smov(Register,
> FloatRegister, S, index)' is used.
>
> We put them into two separate functions and make 'Q' field always set
> for smov. That means 'SMOVX' (64-bit register variant) is generated
> for all cases since it's compatible with our current usages of 'SMOVW'.
> Existing usages of smov have been double checked and this patch does
> not affect them.
>
> 3. Smoke tests are also added.
>
> [1]. https://developer.arm.com/docs/ddi0602/f/simd-and-floating-point-instructions-alphabetic-order/smov-signed-move-vector-element-to-general-purpose-register
> [2]. https://developer.arm.com/docs/ddi0602/f/simd-and-floating-point-instructions-alphabetic-order/umov-unsigned-move-vector-element-to-general-purpose-register
>
>
> Note that Jtreg tier1 and jdk::tier3 have been tested and all tests passed without new failures.
Can anyone help to review this PR? Thanks. :)
-------------
PR: https://git.openjdk.java.net/jdk/pull/1586
More information about the hotspot-compiler-dev
mailing list