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