From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by sourceware.org (Postfix) with ESMTPS id A20803858D1E for ; Mon, 17 Jul 2023 07:11:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A20803858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vrull.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vrull.eu Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-51ff0e3d8c1so5458296a12.0 for ; Mon, 17 Jul 2023 00:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; t=1689577905; x=1692169905; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tlEzdTgRP/rjhSjwrDM4S/DzfreOhQHV4sfShf+daIY=; b=OzEnYkjdPK9Z4umHqBpZs27WF93mpOfRQphvzA9lMSAjjcM2QeTJXvUrQux7l+RPG/ VcY2RBDMgaH2+/mGCOwV3d8BLBx7TXW1G7quMeVXkBjmNvDn9D32feF2cUwF6YhvcHy9 Rk9GSlSyc9H3SUMJ6t3CoLhHJtwrZs9Erot9l8CVpPF8VS+IFSnsSe8EclQfHASJ7Oo7 mpPPBX3xPv+H7iXJew1CmHumSb7pbDqLBtMkgkxqp5ynlCt1RqcbrsStjPqVBZpJuCwf mep/fxesn6ueFtFSmXZyPgxMtl+gAz1MnRrfb5d7hpcp+XUwCotY6NrQh/2lJehaVMa3 JkLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689577905; x=1692169905; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tlEzdTgRP/rjhSjwrDM4S/DzfreOhQHV4sfShf+daIY=; b=cFsE+SGFobtTK7hAnA39VLInuObH6P5ynur0V9l2HqSqf2DnR/4q3aUgpRpi3dOBnw GDNEiNxSop6nq1uWUWt9+O1KF2r+H7FFeGkKwcdwFx/+9IkdzswQ2dmj4ceNF0/jpAXt 7UtNLqqiEGPSauS1HVOOKvS2Npdref/GAqhSs7zgC1qOYRNsF7puZgLgjQxoZhfSybOy 7UfWEhUjClIYnXslja3ICtMMk7qmQfD2fMUGKWQGZDfaMYarNn8HnCGEaXnE3a6xwBWL stfNXE/tFr+AwFs0u3+oQRRi0lE1Qx1i3XTOEKVxxOsTKIrLSKV5MVL/ku0gINTx57nU 0Hmw== X-Gm-Message-State: ABy/qLYyT4bUHoQm3jEnbzy7MUXzjGKXUG7F2aA6P4e8h+D4zRDbKLYz n9xKPohDHd2fw/2+LZaCmABvk8FSc+MS4dEys8c7fQ== X-Google-Smtp-Source: APBJJlGO6G3MHygGvVqbAVVLbvwxy2ee8a7/QjS0Ju20PYMpZMC+88tsvRj1358w2eACTNsbsN7uuEoxm1YigxTqkTE= X-Received: by 2002:a17:907:3a49:b0:988:f1ec:7400 with SMTP id fc9-20020a1709073a4900b00988f1ec7400mr8704133ejc.36.1689577905183; Mon, 17 Jul 2023 00:11:45 -0700 (PDT) MIME-Version: 1.0 References: <20230701052104.4018352-1-christoph.muellner@vrull.eu> <20230701052104.4018352-3-christoph.muellner@vrull.eu> <355e3b07-3111-34dc-7b0f-8be828012ae4@suse.com> In-Reply-To: <355e3b07-3111-34dc-7b0f-8be828012ae4@suse.com> From: Philipp Tomsich Date: Mon, 17 Jul 2023 09:11:34 +0200 Message-ID: Subject: Re: [PATCH v6 02/15] RISC-V: Add support for the Zvbc extension To: Jan Beulich Cc: Christoph Muellner , binutils@sourceware.org, Nathan Huckleberry , nhuck@pmull.org, Jeff Law , Nelson Chu , Andrew Waterman , Palmer Dabbelt , Jim Wilson Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, 17 Jul 2023 at 09:02, Jan Beulich wrote: > > On 01.07.2023 07:20, Christoph Muellner wrote: > > --- a/opcodes/riscv-opc.c > > +++ b/opcodes/riscv-opc.c > > @@ -1902,6 +1902,12 @@ const struct riscv_opcode riscv_opcodes[] = > > {"vwsll.vx", 0, INSN_CLASS_ZVBB, "Vd,Vt,sVm", MATCH_VWSLL_VX, MASK_VWSLL_VX, match_opcode, 0}, > > {"vwsll.vi", 0, INSN_CLASS_ZVBB, "Vd,Vt,VjVm", MATCH_VWSLL_VI, MASK_VWSLL_VI, match_opcode, 0}, > > > > +/* Zvbc instructions. */ > > +{"vclmul.vv", 0, INSN_CLASS_ZVBC, "Vd,Vt,VsVm", MATCH_VCLMUL_VV, MASK_VCLMUL_VV, match_opcode, 0}, > > +{"vclmul.vx", 0, INSN_CLASS_ZVBC, "Vd,Vt,sVm", MATCH_VCLMUL_VX, MASK_VCLMUL_VX, match_opcode, 0}, > > I realize this is more a spec question than an implementation one, but > implementation might be affected by the answer to the question: What > exactly are this and ... > > > +{"vclmulh.vv", 0, INSN_CLASS_ZVBC, "Vd,Vt,VsVm", MATCH_VCLMULH_VV, MASK_VCLMULH_VV, match_opcode, 0}, > > +{"vclmulh.vx", 0, INSN_CLASS_ZVBC, "Vd,Vt,sVm", MATCH_VCLMULH_VX, MASK_VCLMULH_VX, match_opcode, 0}, > > ... this insn doing in RV32 mode? There are no 64 bits to take from > the GPR, yet that's what the doc presently says. Is the value coming > from a pair of GPRs, or is it sign- or zero-extended? Or is this an > RV64-only insn? (Note how the doc explicitly describes the behavior > for vandn's scalar-source form; the only thing left to be implied > there is that truncation / sign-extension are to - I assume - element > size, but maybe that's said somewhere in more general terms. According to the pull-request for the SAIL model (which will in the future be auto-generated into the specification documents and often clarifies on parts of the specification where the English text is ambiguous or imprecise), these are defined for RV64 only: > > +mapping clause encdec = RISCV_VCLMULH_VV(vm, vs1, vs2, vd) if (haveRVV() & haveZvbc() & sizeof(xlen) == 64) > + <-> 0b001101 @ vm @ vs2 @ vs1 @ 0b010 @ vd @ 0b1010111 if (haveRVV() & haveZvbc() & sizeof(xlen) == 64) Consequently, these should only be allowed for RV64. Thanks for catching this! Philipp. > > As a nit: The two vclmulh lines have one too many blanks, resulting > in columns to not be aligned. > > Jan