From: "Jin Guojie" <jinguojie@loongson.cn>
To: "Richard Henderson" <rth@twiddle.net>,
qemu-devel <qemu-devel@nongnu.org>
Cc: "Aurelien Jarno" <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] [PATCH] tcg/mips: Add support for mips64el backend
Date: Mon, 14 Nov 2016 17:33:51 +0800 [thread overview]
Message-ID: <tencent_15C727792D3238FF7AEC75B6@qq.com> (raw)
In-Reply-To: <7348e0bd-9373-6219-f479-70270d03a070@twiddle.net>
Richard,
I have studied your V2 patch
https://lists.nongnu.org/archive/html/qemu-devel/2016-02/msg02969.html
. Though I have not tested this patch on Loongson machine, I feel this
patch has implemented MIPS64 ISA very completely, including big/little
endian, N32 and N64 ABI. The use of #if is more clean. Many corner cases
are well handled. My patch is only a subset of yours.
I wonder why your patch have not be merged into the mainstream.
If I had seen it before, I don't need to waste time reinventing my patch.
Since tcg target for MIPS64 is of great use for developers, I
really hope this feature can be merged into mainstream.
Is your v2 patch still in review process? Is there chance for this
patch to be merged in a not so long term? Or should other code
work should be done before being merged?
I want listen to your advice. Should I test your v2 patch on Loongson
and use it? Or whether it is worth modifying my patch and resubmit it
according to your review comments?
Jin Guojie
------------------ Original ------------------
From: "Richard Henderson";<rth@twiddle.net>;
Send time: Sunday, Nov 13, 2016 3:56 PM
To: "jinguojie"<jinguojie@loongson.cn>; "qemu-devel"<qemu-devel@nongnu.org>;
Cc: "Aurelien Jarno"<aurelien@aurel32.net>;
Subject: Re: [Qemu-devel] [PATCH] tcg/mips: Add support for mips64el backend
On 11/11/2016 08:20 AM, jinguojie@loongson.cn wrote:
> From: Jin Guojie <jinguojie@loongson.cn>
>
> This patch implements TCG mips64r2(little-endian) translation backend.
> Tested on Loongson 3A2000(a MIPS64-compatible CPU) with Fedora Linux 21 Remix.
> linux-0.2.img.bz2 runs well.
> The performance is nearly 10 times higher than tci mode.
>
> https://en.wikipedia.org/wiki/Loongson
> http://www.loongnix.org/index.php/Loongnix
>
> Cc: Aurelien Jarno <aurelien@aurel32.net>
> Signed-off-by: Jin Guojie <jinguojie@loongson.cn>
Have you seen
https://lists.nongnu.org/archive/html/qemu-devel/2016-02/msg01910.html
? I know there are bugs in that patch set, but I would like any mips64 support
to look like that. In particular, reduce the use of #if to an absolute minimum.
> +#if UINTPTR_MAX == UINT32_MAX
> +# define TCG_TARGET_REG_BITS 32
> +#elif UINTPTR_MAX == UINT64_MAX
> +# define TCG_TARGET_REG_BITS 64
> +#endif
There are two mips64 abi's. You're only allowing 64-bit code to be generated
for n64, and not n32.
> +#undef use_movnz_instructions
> +#undef use_mips32_instructions
> +#undef use_mips32r6_instructions
> +
> +#define use_movnz_instructions 0
> +#define use_mips32_instructions 0
> +#define use_mips32r6_instructions 0
Why? Certainly we should be able to generate code for mips64r2 and mips64r6.
> +#if TCG_TARGET_REG_BITS == 64
> +static const TCGReg tcg_target_call_oarg_regs[1] = {
> + TCG_REG_V0,
> +};
> +#else
> static const TCGReg tcg_target_call_oarg_regs[2] = {
> TCG_REG_V0,
> TCG_REG_V1
> };
> +#endif
This change would be incorrect if we ever enhance tcg to handle __int128_t. In
the meantime it doesn't matter, and can be left unchanged.
> @@ -459,7 +502,15 @@ static inline void tcg_out_mov(TCGContext *s, TCGType type,
> {
> /* Simple reg-reg move, optimising out the 'do nothing' case */
> if (ret != arg) {
> +#if TCG_TARGET_REG_BITS == 64
> + if (type == TCG_TYPE_I32) {
> + tcg_out_opc_reg(s, OPC_ADDU, ret, arg, TCG_REG_ZERO);
> + } else {
> + tcg_out_opc_reg(s, OPC_DADDU, ret, arg, TCG_REG_ZERO);
> + }
> +#else
> tcg_out_opc_reg(s, OPC_ADDU, ret, arg, TCG_REG_ZERO);
> +#endif
> }
This is why a proper mips assembler uses OPC_OR.
> }
>
> @@ -470,12 +521,21 @@ static inline void tcg_out_movi(TCGContext *s, TCGType type,
> tcg_out_opc_imm(s, OPC_ADDIU, reg, TCG_REG_ZERO, arg);
> } else if (arg == (uint16_t)arg) {
> tcg_out_opc_imm(s, OPC_ORI, reg, TCG_REG_ZERO, arg);
> - } else {
> + } else if (arg == (int32_t)arg) {
> tcg_out_opc_imm(s, OPC_LUI, reg, TCG_REG_ZERO, arg >> 16);
> if (arg & 0xffff) {
> tcg_out_opc_imm(s, OPC_ORI, reg, reg, arg & 0xffff);
> }
> }
> +#if TCG_TARGET_REG_BITS == 64
> + /* 64-bit imm */
> + else {
> + tcg_out_opc_imm(s, OPC_LUI, reg, 0, (arg >> 32) & 0xffff);
> + tcg_out_opc_imm(s, OPC_ORI, reg, reg, (arg >> 16) & 0xffff);
> + tcg_out_opc_imm_64(s, OPC_DSLL, reg, reg, 16);
> + tcg_out_opc_imm(s, OPC_ORI, reg, reg, arg & 0xffff);
> + }
> +#endif
This is only a 48-bit immediate.
> }
>
> static inline void tcg_out_bswap16(TCGContext *s, TCGReg ret, TCGReg arg)
> @@ -566,7 +626,11 @@ static void tcg_out_ldst(TCGContext *s, MIPSInsn opc, TCGReg data,
> if (ofs != lo) {
> tcg_out_movi(s, TCG_TYPE_PTR, TCG_TMP0, ofs - lo);
> if (addr != TCG_REG_ZERO) {
> +#if TCG_TARGET_REG_BITS == 64
> + tcg_out_opc_reg(s, OPC_DADDU, TCG_TMP0, TCG_TMP0, addr);
> +#else
> tcg_out_opc_reg(s, OPC_ADDU, TCG_TMP0, TCG_TMP0, addr);
> +#endif
See my patchset where I introduce OPC_PADDU to avoid this and other similar ifdefs.
> @@ -1163,6 +1276,7 @@ static void tcg_out_qemu_ld_slow_path(TCGContext *s, TCGLabelQemuLdst *l)
> tcg_out_mov(s, TCG_TYPE_PTR, tcg_target_call_iarg_regs[0], TCG_AREG0);
>
> v0 = l->datalo_reg;
> +#if TCG_TARGET_REG_BITS == 32
> if ((opc & MO_SIZE) == MO_64) {
> /* We eliminated V0 from the possible output registers, so it
> cannot be clobbered here. So we must move V1 first. */
> @@ -1173,11 +1287,21 @@ static void tcg_out_qemu_ld_slow_path(TCGContext *s, TCGLabelQemuLdst *l)
> tcg_out_mov(s, TCG_TYPE_I32, l->datahi_reg, TCG_REG_V1);
> }
> }
> +#endif
>
> reloc_pc16(s->code_ptr, l->raddr);
> tcg_out_opc_br(s, OPC_BEQ, TCG_REG_ZERO, TCG_REG_ZERO);
> /* delay slot */
> +#if TCG_TARGET_REG_BITS == 32
> tcg_out_mov(s, TCG_TYPE_REG, v0, TCG_REG_V0);
> +#else
> + /* ext unsigned long(32) -> 64-bit */
> + if ((opc & MO_SIZE) == MO_32) {
> + tcg_out_mov(s, TCG_TYPE_I32, v0, TCG_REG_V0);
> + } else {
> + tcg_out_mov(s, TCG_TYPE_REG, v0, TCG_REG_V0);
> + }
> +#endif
This is incorrect, as you're not passing down whether the operation is a 32-bit
load into a 32-bit temporary, or a 32-bit load into a 64-bit temporary. I.e.
the difference between
unsigned int x = *(unsigned int *)ptr;
and
unsigned long long x = *(unsigned int *)ptr;
r~
next prev parent reply other threads:[~2016-11-14 9:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-11 7:20 [Qemu-devel] [PATCH] tcg/mips: Add support for mips64el backend jinguojie
2016-11-13 7:56 ` Richard Henderson
2016-11-14 9:33 ` Jin Guojie [this message]
2016-11-14 16:24 ` Aurelien Jarno
2016-11-15 21:37 ` Richard Henderson
2016-11-16 10:52 ` James Hogan
-- strict thread matches above, loose matches on Subject: below --
2016-11-16 1:58 Jin Guojie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=tencent_15C727792D3238FF7AEC75B6@qq.com \
--to=jinguojie@loongson.cn \
--cc=aurelien@aurel32.net \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.