From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by sourceware.org (Postfix) with ESMTPS id 00CFB3858D38 for ; Tue, 27 Dec 2022 19:47:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 00CFB3858D38 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-ej1-x62d.google.com with SMTP id ud5so34013785ejc.4 for ; Tue, 27 Dec 2022 11:47:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=14RiyGoRfWVuPE8c6W8WKEGDa6tkxfwbiySg9/8X13U=; b=cLXTRqXTW+Z7h66I+VAAsukg/IqVnjsu8JC57KaoOyVWSQOE9hdR+ssh6eKMnnSeeX l5kJ2JDBhi7RlNUGp8O4YuKtEnZiWMTSNo1exaUlmQ3MmdhU3mzt7lrVmc2BeqsongWo 2xu8rpkohDubsTewf9aMZahYTlbOlSzC7E4xWPxE4aZ6IW7fTJ/oEm7eDkW9pJKm0G3h 1FWaTa/oaNQOihvevuJBdkuwvxIdyVHWuuRjSXEXVk7Pz3cWQsj4S7QTshPDCvEAZwHh MzgNZ+ZFpa29Zkr266enAwX5+fhK+y7pqzwn57mPJ68UXYK5TFJ/ReV/dD2WyqamfaDI Uh4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=14RiyGoRfWVuPE8c6W8WKEGDa6tkxfwbiySg9/8X13U=; b=aJTS6/I0VxaT/veobx49nhuWgpRPAE5ZbddECkeZ+LsogjxiUpr5Dy+eszl7ouQXRZ snhKkbNeAtElhZAtT7eoNGKbFAC49KYKj5gTqtjx3ZAVMsMpz2EMHWT5F9McI8Ag7Bu4 jWWTlobNvNNA9lzsq31INrwR8l8gfStkf5CXjWt/izvQwoxxR+CRleiArmWlRPWSdyPY Q87FU6ZcY7tFu/VyE7MAE2jxeDvm1KLRIcvmMvY6Wnk83ivEeVznDgSOPBbGzGe2Ll2I uxrfXmCHJZlzFCPrPC2DJf7WJaVgvrsOBx7aupD/+by5bWjFlTEfUJZV6ezOYuoIwNV8 D9hg== X-Gm-Message-State: AFqh2koEvZXkF2H/RdIsbisg4RB0vtX79EmEibfqjdHWtu+K+NmCDW5m S7YR16GPkRqa9RmJfDBumF4Ivi3pikfNz7UUFMdRaA== X-Google-Smtp-Source: AMrXdXu4xDfWT8hJiXDstkdRHgimtpuTLk1rV7R2YPyk58zplb/bqKO3ze3B4SGpZhG8a5GLrwF66lylBeYIhfFHIzc= X-Received: by 2002:a17:906:4ecb:b0:7bc:2ad:fae with SMTP id i11-20020a1709064ecb00b007bc02ad0faemr1565449ejv.724.1672170450675; Tue, 27 Dec 2022 11:47:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Philipp Tomsich Date: Tue, 27 Dec 2022 20:47:19 +0100 Message-ID: Subject: Re: [RFC PATCH] RISC-V: Add support for vector crypto extensions To: Palmer Dabbelt Cc: gcc-patches@gcc.gnu.org, christoph.muellner@vrull.eu, kito.cheng@sifive.com, Jim Wilson , Andrew Waterman , Aaron Durbin , Vineet Gupta , Andrew de los Reyes , ego@rivosinc.com, Barna Ibrahim Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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 Tue, 27 Dec 2022 at 19:58, Palmer Dabbelt wrote: > > On Tue, 27 Dec 2022 09:35:55 PST (-0800), gcc-patches@gcc.gnu.org wrote: > > > > > > On 12/21/22 11:31, Christoph Muellner wrote: > >> From: Christoph M=C3=BCllner > >> > >> This series adds basic support for the vector crypto extensions: > >> * Zvkb > >> * Zvkg > >> * Zvkh[a,b] > >> * Zvkn > >> * Zvksed > >> * Zvksh > >> > >> The implementation follows the version 20221220 of the specification, > >> which can be found here: > >> https://github.com/riscv/riscv-crypto/releases/tag/v20221220 > >> > >> Note, that this specification is not frozen yet, meaning that > >> incompatible changes are possible. > >> Therefore, this patchset is marked as RFC and should not be considered > >> for upstream inclusion. > >> > >> All extensions come with (passing) tests for the feature test macros. > >> > >> A Binutils patch series for vector crypto support can be found here: > >> https://sourceware.org/pipermail/binutils/2022-December/125272.html > >> > >> Signed-off-by: Christoph M=C3=BCllner > >> --- > >> gcc/common/config/riscv/riscv-common.cc | 16 ++++++++++++++++ > >> gcc/config/riscv/riscv-opts.h | 16 ++++++++++++++++ > >> gcc/config/riscv/riscv.opt | 3 +++ > >> gcc/testsuite/gcc.target/riscv/zvkb.c | 13 +++++++++++++ > >> gcc/testsuite/gcc.target/riscv/zvkg.c | 13 +++++++++++++ > >> gcc/testsuite/gcc.target/riscv/zvkha.c | 13 +++++++++++++ > >> gcc/testsuite/gcc.target/riscv/zvkhb.c | 13 +++++++++++++ > >> gcc/testsuite/gcc.target/riscv/zvkn.c | 13 +++++++++++++ > >> gcc/testsuite/gcc.target/riscv/zvksed.c | 13 +++++++++++++ > >> gcc/testsuite/gcc.target/riscv/zvksh.c | 13 +++++++++++++ > >> 10 files changed, 126 insertions(+) > >> create mode 100644 gcc/testsuite/gcc.target/riscv/zvkb.c > >> create mode 100644 gcc/testsuite/gcc.target/riscv/zvkg.c > >> create mode 100644 gcc/testsuite/gcc.target/riscv/zvkha.c > >> create mode 100644 gcc/testsuite/gcc.target/riscv/zvkhb.c > >> create mode 100644 gcc/testsuite/gcc.target/riscv/zvkn.c > >> create mode 100644 gcc/testsuite/gcc.target/riscv/zvksed.c > >> create mode 100644 gcc/testsuite/gcc.target/riscv/zvksh.c > > I don't see anything objectionable in here. I'd guess that most (but > > perhaps not all) of these will wire up as builtins at some point in the > > not too distant future. > > These allow things like `-march=3Drv64gc_zvksh`, it's not really clear > what the indented behavior is there -- specifically, does that > implicitly enable some base vector extension? > > I've just skimmed the ISA manual here, but all I can find is a bit > ambiguous > > With the exception of Zvknhb, each of these Vector Crypto Extensions > can be build on any base Vector Extension, embedded (Zve*) or > application ("V"). Zvknhb requires ELEN=3D64 and therefore cannot be > implemented on a Zve32* base. > > I doubt it really matters which way we pick, but it is something we're > going to need to keep consistent moving forwards as otherwise users > might get some surprising behavior. This has come up a bunch of times, > but there's slightly different wording each time in the specs and I'm > never really sure what to read of it. > > I don't think that alone would be enough to delay this for gcc-14, but > as far as I can tell binutils is branching very soon for a target > release in the middle of January. I'm guessing these extensions will > not be frozen by then, which would be a blocker. > > I'm not sure if anyone has a pressing need for these? If not, I think > it's best to delay them until binutils-2.41 (and presumably then > gcc-14). Given that the encodings last changed on Dec 21st, I would also prefer if we could off until after the binutils-2.40 has been released. Philipp.