Integrated: 8324123: aarch64: fix prfm literal encoding in assembler
Wang Zhuo
wzhuo at openjdk.org
Fri Jan 26 02:33:41 UTC 2024
On Thu, 18 Jan 2024 10:02:59 GMT, Wang Zhuo <wzhuo at openjdk.org> wrote:
> Current prfm literal mode encoding in aarch64 assembler is not correct.
> The prfm_literal instruction requires 31 and 30 bits to be 0x11, while current assembler encodes the two bits to be 0x11, which is a ldr instruction, not prfm.
> For example, if adding the following code in stubGenerator
> __ prfm(Address(__ pc()))
> we get a ldr instruction like
> ldr x0, 0x0000ffff83f8539c
> but it should be a prfm instruction like
> prfm pldl1keep, 0x0000ffff8ff8539c
>
> The bug is caused in ld_st2, literal mode, bit 31 and 30 bits are set to (size & 0b01), while for prfm instructions, 31 and 30 bits must be 0b11.
> void ld_st2(Register Rt, const Address &adr, int size, int op, int V = 0) {
> starti;
>
> f(V, 26); // general reg?
> zrf(Rt, 0);
>
> // Encoding for literal loads is done here (rather than pushed
> // down into Address::encode) because the encoding of this
> // instruction is too different from all of the other forms to
> // make it worth sharing.
> if (adr.getMode() == Address::literal) {
> assert(size == 0b10 || size == 0b11, "bad operand size in ldr");
> assert(op == 0b01, "literal form can only be used with loads");
> f(**size & 0b01, 31, 30**), f(0b011, 29, 27), f(0b00, 25, 24);
> int64_t offset = (adr.target() - pc()) >> 2;
> sf(offset, 23, 5);
> code_section()->relocate(pc(), adr.rspec());
> return;
> }
>
> f(size, 31, 30);
> f(op, 23, 22); // str
> adr.encode(¤t_insn);
> }
This pull request has now been integrated.
Changeset: bde87895
Author: Wang Zhuo <wzhuo at openjdk.org>
Committer: Denghui Dong <ddong at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/bde87895c8b1b9df198e3883d24cd9ea840efc98
Stats: 33 lines in 2 files changed: 22 ins; 11 del; 0 mod
8324123: aarch64: fix prfm literal encoding in assembler
Reviewed-by: aph, dlong
-------------
PR: https://git.openjdk.org/jdk/pull/17482
More information about the hotspot-compiler-dev
mailing list