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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).