public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Palmer Dabbelt <palmer@dabbelt.com>
To: gcc-patches@gcc.gnu.org
Cc: christoph.muellner@vrull.eu, gcc-patches@gcc.gnu.org,
	kito.cheng@sifive.com, Jim Wilson <jim.wilson.gcc@gmail.com>,
	Andrew Waterman <andrew@sifive.com>,
	philipp.tomsich@vrull.eu, Aaron Durbin <adurbin@rivosinc.com>,
	Vineet Gupta <vineetg@rivosinc.com>,
	Andrew de los Reyes <adlr@rivosinc.com>,
	ego@rivosinc.com, Barna Ibrahim <barna@rivosinc.com>
Subject: Re: [RFC PATCH] RISC-V: Add support for vector crypto extensions
Date: Tue, 27 Dec 2022 10:58:37 -0800 (PST)	[thread overview]
Message-ID: <mhng-dccc9390-54a4-4d1e-9b85-3042dd720a48@palmer-ri-x1c9a> (raw)
In-Reply-To: <d80665f1-4743-6083-be6e-c7900703d1b5@gmail.com>

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üllner <christoph.muellner@vrull.eu>
>>
>> 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üllner <christoph.muellner@vrull.eu>
>> ---
>>   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=rv64gc_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=64 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).

  reply	other threads:[~2022-12-27 18:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-21 18:31 Christoph Muellner
2022-12-27 17:35 ` Jeff Law
2022-12-27 18:58   ` Palmer Dabbelt [this message]
2022-12-27 19:47     ` Philipp Tomsich

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=mhng-dccc9390-54a4-4d1e-9b85-3042dd720a48@palmer-ri-x1c9a \
    --to=palmer@dabbelt.com \
    --cc=adlr@rivosinc.com \
    --cc=adurbin@rivosinc.com \
    --cc=andrew@sifive.com \
    --cc=barna@rivosinc.com \
    --cc=christoph.muellner@vrull.eu \
    --cc=ego@rivosinc.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jim.wilson.gcc@gmail.com \
    --cc=kito.cheng@sifive.com \
    --cc=philipp.tomsich@vrull.eu \
    --cc=vineetg@rivosinc.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 read-only IMAP folder(s) and NNTP newsgroup(s).