On 28.08.2025 15:02, Song Gao wrote:
From: WANG Rui <[email protected]>
This patch replaces uses of the generic TRANS macro with TRANS64 for
instructions that are only valid when 64-bit support is available.
This improves correctness and avoids potential assertion failures or
undefined behavior during translation on 32-bit-only configurations.
Hi!
This change has been CC'd to qemu-stable, apparently aimed for
the previous qemu stable series as well. Current relevant long-
term stable series is 10.0. However, this hunk:
..
--- a/target/loongarch/tcg/insn_trans/trans_extra.c.inc
+++ b/target/loongarch/tcg/insn_trans/trans_extra.c.inc
@@ -100,8 +104,8 @@ static bool gen_crc(DisasContext *ctx, arg_rrr *a,
TRANS(crc_w_b_w, CRC, gen_crc, gen_helper_crc32, tcg_constant_tl(1))
TRANS(crc_w_h_w, CRC, gen_crc, gen_helper_crc32, tcg_constant_tl(2))
TRANS(crc_w_w_w, CRC, gen_crc, gen_helper_crc32, tcg_constant_tl(4))
-TRANS(crc_w_d_w, CRC, gen_crc, gen_helper_crc32, tcg_constant_tl(8))
+TRANS64(crc_w_d_w, CRC, gen_crc, gen_helper_crc32, tcg_constant_tl(8))
TRANS(crcc_w_b_w, CRC, gen_crc, gen_helper_crc32c, tcg_constant_tl(1))
TRANS(crcc_w_h_w, CRC, gen_crc, gen_helper_crc32c, tcg_constant_tl(2))
TRANS(crcc_w_w_w, CRC, gen_crc, gen_helper_crc32c, tcg_constant_tl(4))
-TRANS(crcc_w_d_w, CRC, gen_crc, gen_helper_crc32c, tcg_constant_tl(8))
+TRANS64(crcc_w_d_w, CRC, gen_crc, gen_helper_crc32c, tcg_constant_tl(8))
does not apply to 10.0 directly, since 10.0 branch misses this:
commit 256df51e727235b3d5e937ca2784c45663c00f59
Author: WANG Rui <[email protected]>
Date: Fri Apr 18 16:21:01 2025 +0800
target/loongarch: Add CRC feature flag and use it to gate CRC
instructions
Since 10.0.x supposed to be a long-term series, are you okay if I
pick commit 256df51e727235 to 10.0.x too, before this TRANS64 one?
From the description of 256df51e727235 it looks like it should've been
Cc'd qemu-stable too.
What I'm thinking: for long-term stable series, it might be best to
keep the code as close to the master branch as possible, and instead
of adapting fixes from master to the context in the stable branch, it
is often better to pick up preceeding changes and apply the fix as-is
without modifications.
The same applies to the second patch in this series, btw, -- the second
patch also does not apply to 10.0.x directly because 10.0 lacks commit
ab9bbee3c7da3 "hw/intc/loongarch_pch: Modify name of some registers" --
the commit is just some code renames, it does not change actual code, so
it is a no-op, but it makes subsequent changes to not apply directly.
I think I'll pick ab9bbee3c7da3 and the next one, 4f0f2ab5640ef
"hw/intc/loongarch_pch: Modify register name PCH_PIC_xxx_OFFSET..",
to 10.0.x too.
It looks like this code will receive more fixes in the future. And
this' way, we can keep loongarch support in 10.0.x for longer and make
it better.
Does it all make sense?
Thanks,
/mjt
