From: Richard Henderson <richard.henderson@linaro.org>
To: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>, qemu-devel@nongnu.org
Cc: qemu-riscv@nongnu.org, palmer@dabbelt.com,
alistair.francis@wdc.com, dbarboza@ventanamicro.com,
liwei1518@gmail.com, bmeng.cn@gmail.com,
TANG Tiancheng <tangtiancheng.ttc@alibaba-inc.com>
Subject: Re: [PATCH v5 03/12] tcg/riscv: Add vset{i}vli and ld/st vec ops
Date: Mon, 7 Oct 2024 09:24:01 -0700 [thread overview]
Message-ID: <a370de66-d966-44d2-9dee-091b28082fcc@linaro.org> (raw)
In-Reply-To: <20241007025700.47259-4-zhiwei_liu@linux.alibaba.com>
On 10/6/24 19:56, LIU Zhiwei wrote:
> +static void probe_frac_lmul(void)
> +{
> + unsigned long vlmax[3];
> +
> + for (int i = MO_8; i <= MO_64; ++i) {
> + switch (i) {
> + case MO_8:
> + asm volatile(
> + "vsetvli %0, zero, e8, mf2\n\t"
> + "vsetvli %1, zero, e8, mf4\n\t"
> + "vsetvli %2, zero, e8, mf8"
> + : "=r"(vlmax[0]), "=r"(vlmax[1]), "=r"(vlmax[2])
> + );
> + break;
> + case MO_16:
> + asm volatile(
> + "vsetvli %0, zero, e16, mf2\n\t"
> + "vsetvli %1, zero, e16, mf4\n\t"
> + "vsetvli %2, zero, e16, mf8"
> + : "=r"(vlmax[0]), "=r"(vlmax[1]), "=r"(vlmax[2])
> + );
> + break;
> + case MO_32:
> + asm volatile(
> + "vsetvli %0, zero, e32, mf2\n\t"
> + "vsetvli %1, zero, e32, mf4\n\t"
> + "vsetvli %2, zero, e32, mf8"
> + : "=r"(vlmax[0]), "=r"(vlmax[1]), "=r"(vlmax[2])
> + );
> + break;
> + case MO_64:
> + asm volatile(
> + "vsetvli %0, zero, e64, mf2\n\t"
> + "vsetvli %1, zero, e64, mf4\n\t"
> + "vsetvli %2, zero, e64, mf8"
> + : "=r"(vlmax[0]), "=r"(vlmax[1]), "=r"(vlmax[2])
> + );
> + break;
> + default:
> + g_assert_not_reached();
> + }
> + vaild_frac_lmul[i][1] = vlmax[0] != 0;
> + vaild_frac_lmul[i][2] = vlmax[1] != 0;
> + vaild_frac_lmul[i][3] = vlmax[2] != 0;
> + }
> }
This fails to build on debian with default cflags:
/home/rth/qemu/src/tcg/riscv/tcg-target.c.inc: Assembler messages:
/home/rth/qemu/src/tcg/riscv/tcg-target.c.inc:2880: Error: unrecognized opcode `vsetvli
a3,zero,e8,mf2', extension `v' or `zve64x' or `zve32x' required
/home/rth/qemu/src/tcg/riscv/tcg-target.c.inc:2881: Error: unrecognized opcode `vsetvli
a4,zero,e8,mf4', extension `v' or `zve64x' or `zve32x' required
/home/rth/qemu/src/tcg/riscv/tcg-target.c.inc:2882: Error: unrecognized opcode `vsetvli
a5,zero,e8,mf8', extension `v' or `zve64x' or `zve32x' required
/home/rth/qemu/src/tcg/riscv/tcg-target.c.inc:2888: Error: unrecognized opcode `vsetvli
a3,zero,e16,mf2', extension `v' or `zve64x' or `zve32x' required
/home/rth/qemu/src/tcg/riscv/tcg-target.c.inc:2889: Error: unrecognized opcode `vsetvli
a4,zero,e16,mf4', extension `v' or `zve64x' or `zve32x' required
/home/rth/qemu/src/tcg/riscv/tcg-target.c.inc:2890: Error: unrecognized opcode `vsetvli
a5,zero,e16,mf8', extension `v' or `zve64x' or `zve32x' required
/home/rth/qemu/src/tcg/riscv/tcg-target.c.inc:2896: Error: unrecognized opcode `vsetvli
a3,zero,e32,mf2', extension `v' or `zve64x' or `zve32x' required
/home/rth/qemu/src/tcg/riscv/tcg-target.c.inc:2897: Error: unrecognized opcode `vsetvli
a4,zero,e32,mf4', extension `v' or `zve64x' or `zve32x' required
/home/rth/qemu/src/tcg/riscv/tcg-target.c.inc:2898: Error: unrecognized opcode `vsetvli
a5,zero,e32,mf8', extension `v' or `zve64x' or `zve32x' required
/home/rth/qemu/src/tcg/riscv/tcg-target.c.inc:2904: Error: unrecognized opcode `vsetvli
a3,zero,e64,mf2', extension `v' or `zve64x' or `zve32x' required
/home/rth/qemu/src/tcg/riscv/tcg-target.c.inc:2905: Error: unrecognized opcode `vsetvli
a4,zero,e64,mf4', extension `v' or `zve64x' or `zve32x' required
/home/rth/qemu/src/tcg/riscv/tcg-target.c.inc:2906: Error: unrecognized opcode `vsetvli
a5,zero,e64,mf8', extension `v' or `zve64x' or `zve32x' required
Rather than expanding this with a switch over immediate encodings, perhaps better feed
encode_vtype() to the .insn encoding of vsetvl.
> @@ -2160,6 +2483,7 @@ static void tcg_target_init(TCGContext *s)
> tcg_target_available_regs[TCG_TYPE_V256] = ALL_VECTOR_REGS;
> break;
> }
> + probe_frac_lmul();
You need to avoid this call if the host does not support vectors.
It occurs to me that, rather than caching valid_frac_lmul[][], we can pre-compute
encode_vtype and lmul_eq_avl. It's not much of a savings within set_vtype(), but perhaps
it is clearer.
r~
next prev parent reply other threads:[~2024-10-07 16:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-07 2:56 [PATCH v5 00/12] tcg/riscv: Add support for vector LIU Zhiwei
2024-10-07 2:56 ` [PATCH v5 01/12] util: Add RISC-V vector extension probe in cpuinfo LIU Zhiwei
2024-10-07 2:56 ` [PATCH v5 02/12] tcg/riscv: Add basic support for vector LIU Zhiwei
2024-10-07 16:24 ` Richard Henderson
2024-10-09 1:38 ` Richard Henderson
2024-10-07 2:56 ` [PATCH v5 03/12] tcg/riscv: Add vset{i}vli and ld/st vec ops LIU Zhiwei
2024-10-07 16:24 ` Richard Henderson [this message]
2024-10-08 8:51 ` LIU Zhiwei
2024-10-08 13:18 ` Richard Henderson
2024-10-07 2:56 ` [PATCH v5 04/12] tcg/riscv: Implement vector mov/dup{m/i} LIU Zhiwei
2024-10-07 2:56 ` [PATCH v5 05/12] tcg/riscv: Add support for basic vector opcodes LIU Zhiwei
2024-10-07 2:56 ` [PATCH v5 06/12] tcg/riscv: Implement vector cmp/cmpsel ops LIU Zhiwei
2024-10-07 2:56 ` [PATCH v5 07/12] tcg/riscv: Implement vector neg ops LIU Zhiwei
2024-10-07 2:56 ` [PATCH v5 08/12] tcg/riscv: Implement vector sat/mul ops LIU Zhiwei
2024-10-07 2:56 ` [PATCH v5 09/12] tcg/riscv: Implement vector min/max ops LIU Zhiwei
2024-10-07 2:56 ` [PATCH v5 10/12] tcg/riscv: Implement vector shi/s/v ops LIU Zhiwei
2024-10-07 2:56 ` [PATCH v5 11/12] tcg/riscv: Implement vector roti/v/x ops LIU Zhiwei
2024-10-07 2:57 ` [PATCH v5 12/12] tcg/riscv: Enable native vector support for TCG host LIU Zhiwei
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=a370de66-d966-44d2-9dee-091b28082fcc@linaro.org \
--to=richard.henderson@linaro.org \
--cc=alistair.francis@wdc.com \
--cc=bmeng.cn@gmail.com \
--cc=dbarboza@ventanamicro.com \
--cc=liwei1518@gmail.com \
--cc=palmer@dabbelt.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=tangtiancheng.ttc@alibaba-inc.com \
--cc=zhiwei_liu@linux.alibaba.com \
/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).