Message ID | 1631497278-29829-1-git-send-email-vincent.chen@sifive.com |
---|---|
Headers |
Return-Path: <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 98A183858039 for <patchwork@sourceware.org>; Mon, 13 Sep 2021 01:41:47 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) by sourceware.org (Postfix) with ESMTPS id D489A3858429 for <libc-alpha@sourceware.org>; Mon, 13 Sep 2021 01:41:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D489A3858429 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-pg1-x529.google.com with SMTP id w8so7903131pgf.5 for <libc-alpha@sourceware.org>; Sun, 12 Sep 2021 18:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=from:to:cc:subject:date:message-id; bh=u8ApVArbN7zZIWMBRCz72XGrOXRzRKK+XUGnA4K3SV4=; b=Z0DNHH84MY4VqqtzDBLqyc0E59YYG2sA8Mqsq65KuVYkJC5XDMmYp/HMzlznUqyjuF dybys4Jk0iFeEei+Nk3q+hU1Q3FeJ7wueRjphAHVvuKKMlujMhb13VGbsrIRUr1UpBxw hA/WxnOnbmcFKlfdbphK4rjM6YsJD4R+ficvGxNqEk6A3fIzzbcEPRfWMzzjttUVSJfX 0Ukl3hvu/JDWAiLb1Nrz8bywJIerkkzb4WyoWhrBwkvsa7A6FZAVWZjkopyUBsjsfqtB pU/1ZpSRmhpITSGMcAl0TzO3RA2mNvXb+1feDAV87KrbWPY6LYMoDY6MLFF7Wsa1WjCw 2hdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=u8ApVArbN7zZIWMBRCz72XGrOXRzRKK+XUGnA4K3SV4=; b=HNyld0rLWksWR2WX8p/OdEY/3I0DQcq++Z5WTM+165H8+Gvuh/j/w9/seI7evTyaCd Z4NRN6qU1v5DY6/xm1IWOfaf5sZBDLxHL+RfkW2MRcu5zjHVPz8Avh/NJrJOsxFUUdJ8 m7eFeWaC/7MAei4i1gXbhCC2HnSrxlCIIo92xshHyxysH/S/eE3vsrf6kXI81aRW4BFg nlv02dGZU5SmUhy10cmHcuMtydZfBiAAeYIyn845cZEuL1r4b4jBrVkOc5skLRuyAAz/ f+boK44LsdStpCuuor87IzKYhQOy07W3o/aUlASlbShXTzeQARU8rUgQ7HATQDlF6Egf sh3w== X-Gm-Message-State: AOAM530bn/uznsXfl2nFG5I1P0ClUIPDxVMxzSlELz8QZwSGDmFIQO1J bx7PXKlxQb70AzrolDCfwEQIhp5P3RzRww== X-Google-Smtp-Source: ABdhPJyNz0nGXC+Mk/fb1yVHk8oBX8G1TZL+6zJ+Be4jbIn0CG0WDjQxcAqNi+jzZcW4fbuuYkyCmA== X-Received: by 2002:a63:ed17:: with SMTP id d23mr8834327pgi.29.1631497290729; Sun, 12 Sep 2021 18:41:30 -0700 (PDT) Received: from localhost.localdomain (36-227-141-62.dynamic-ip.hinet.net. [36.227.141.62]) by smtp.gmail.com with ESMTPSA id i10sm5052173pfk.87.2021.09.12.18.41.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Sep 2021 18:41:30 -0700 (PDT) From: Vincent Chen <vincent.chen@sifive.com> To: libc-alpha@sourceware.org, palmer@dabbelt.com Subject: [RFC patch 0/5] RISC-V: Add vector ISA support Date: Mon, 13 Sep 2021 09:41:13 +0800 Message-Id: <1631497278-29829-1-git-send-email-vincent.chen@sifive.com> X-Mailer: git-send-email 2.7.4 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> Cc: andrew@sifive.com, Vincent Chen <vincent.chen@sifive.com> Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
RISC-V: Add vector ISA support
|
|
Message
Vincent Chen
Sept. 13, 2021, 1:41 a.m. UTC
This patchset adds required ports to support RISC-V Vector (RVV) extension. Since the length of the vector register in RVV (the theoretical maximum is 2^XLEN-1 bits) is variable, a huge and flexible space is needed to back up all vector registers in the signal context. This patchset expands the default SIGSTKSZ, MINSIGSTKSZ, and PTHREAD_STACK_MIN to ensure the stack size is enough for the normal case (VLENB <= 128 bytes). Linux kernel also places the exact minimum signal stack size in AT_MINSIGSTKSZ entry of the auxiliary vector to inform user, so user still can know the sutible minimum signal stack size by sysconf (_SC_MINSIGSTKSZ) if the VLENB is greater than 128 bytes. In addition, according to the specification, the VCSR that combines VXRM and VXSAT has thread storage duration, so this patchset adds the required user context operation for it. Finally, the RISC-V glibc customized sigcontext.h has been removed in this patchset. to reduce the synchronization work when new extension support is introduced to the Linux environment. However, it may bring some backward incompatible issues. Therefore, I sent an RFC patch (https://sourceware.org/pipermail/libc-alpha/2020-June/115549.html) to discuss this modification before this patchset. As I mentioned in the RFC patch thread, I used OpenEmbeded to evaluate the impact. During the tests, I didn't get any compiler errors. Therefore, I infer that this modification may not cause server backward incompatible issues at this moment. 1. The RISC-V V-extension draft v1.0 can be found in https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc 2. The associated kernel implementation can be found in http://lists.infradead.org/pipermail/linux-riscv/2021-September/008249.html 3. QEMU with RISC-V V-extension support can be found in https://github.com/sifive/qemu/tree/rvv-1.0 Vincent Chen (5): RISC-V: Remove riscv-specific sigcontext.h RISC-V: Reserve about 5K space in mcontext_t to support future ISA expansion. RISC-V: Save and restore VCSR when doing user context switch RISC-V: Extend MINSIGSTKSZ and SIGSTKSZ to backup RVV registers RISC-V: Expand PTHREAD_STACK_MIN to support RVV environment sysdeps/riscv/Makefile | 5 +++ sysdeps/riscv/rtld-global-offsets.sym | 7 ++++ sysdeps/unix/sysv/linux/riscv/bits/hwcap.h | 31 ++++++++++++++++ .../unix/sysv/linux/riscv/bits/pthread_stack_min.h | 21 +++++++++++ sysdeps/unix/sysv/linux/riscv/bits/sigcontext.h | 31 ---------------- sysdeps/unix/sysv/linux/riscv/bits/sigstack.h | 32 +++++++++++++++++ sysdeps/unix/sysv/linux/riscv/getcontext.S | 22 +++++++++++- sysdeps/unix/sysv/linux/riscv/setcontext.S | 22 ++++++++++++ sysdeps/unix/sysv/linux/riscv/swapcontext.S | 41 ++++++++++++++++++++++ sysdeps/unix/sysv/linux/riscv/sys/ucontext.h | 2 ++ .../sysv/linux/riscv/sysconf-pthread_stack_min.h | 39 ++++++++++++++++++++ sysdeps/unix/sysv/linux/riscv/sysdep.h | 1 + sysdeps/unix/sysv/linux/riscv/ucontext_i.sym | 6 ++++ 13 files changed, 228 insertions(+), 32 deletions(-) create mode 100644 sysdeps/riscv/rtld-global-offsets.sym create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/hwcap.h create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/pthread_stack_min.h delete mode 100644 sysdeps/unix/sysv/linux/riscv/bits/sigcontext.h create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/sigstack.h create mode 100644 sysdeps/unix/sysv/linux/riscv/sysconf-pthread_stack_min.h
Comments
On 9/12/21 6:41 PM, Vincent Chen wrote: > This patchset adds required ports to support RISC-V Vector (RVV) extension. > > Since the length of the vector register in RVV (the theoretical maximum > is 2^XLEN-1 bits) is variable, a huge and flexible space is needed to back > up all vector registers in the signal context. This patchset expands the > default SIGSTKSZ, MINSIGSTKSZ, and PTHREAD_STACK_MIN to ensure the stack > size is enough for the normal case (VLENB <= 128 bytes). Linux kernel also > places the exact minimum signal stack size in AT_MINSIGSTKSZ entry of the > auxiliary vector to inform user, so user still can know the sutible minimum > signal stack size by sysconf (_SC_MINSIGSTKSZ) if the VLENB is greater > than 128 bytes. > > In addition, according to the specification, the VCSR that combines VXRM and > VXSAT has thread storage duration, so this patchset adds the required user > context operation for it. > > Finally, the RISC-V glibc customized sigcontext.h has been removed in this > patchset. to reduce the synchronization work when new extension support is > introduced to the Linux environment. However, it may bring some backward > incompatible issues. Therefore, I sent an RFC patch > (https://sourceware.org/pipermail/libc-alpha/2020-June/115549.html) > to discuss this modification before this patchset. As I mentioned in the > RFC patch thread, I used OpenEmbeded to evaluate the impact. During the > tests, I didn't get any compiler errors. Therefore, I infer that this > modification may not cause server backward incompatible issues at this > moment. > > 1. The RISC-V V-extension draft v1.0 can be found in > https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc > 2. The associated kernel implementation can be found in > http://lists.infradead.org/pipermail/linux-riscv/2021-September/008249.html > 3. QEMU with RISC-V V-extension support can be found in > https://github.com/sifive/qemu/tree/rvv-1.0 What about gcc/binutils: sifive forks for those have quite a few branches with rvv suffix, but it is not obvious which one pertains to the specific version implemented in qemu above. Thx, -Vineet > > Vincent Chen (5): > RISC-V: Remove riscv-specific sigcontext.h > RISC-V: Reserve about 5K space in mcontext_t to support future ISA > expansion. > RISC-V: Save and restore VCSR when doing user context switch > RISC-V: Extend MINSIGSTKSZ and SIGSTKSZ to backup RVV registers > RISC-V: Expand PTHREAD_STACK_MIN to support RVV environment > > sysdeps/riscv/Makefile | 5 +++ > sysdeps/riscv/rtld-global-offsets.sym | 7 ++++ > sysdeps/unix/sysv/linux/riscv/bits/hwcap.h | 31 ++++++++++++++++ > .../unix/sysv/linux/riscv/bits/pthread_stack_min.h | 21 +++++++++++ > sysdeps/unix/sysv/linux/riscv/bits/sigcontext.h | 31 ---------------- > sysdeps/unix/sysv/linux/riscv/bits/sigstack.h | 32 +++++++++++++++++ > sysdeps/unix/sysv/linux/riscv/getcontext.S | 22 +++++++++++- > sysdeps/unix/sysv/linux/riscv/setcontext.S | 22 ++++++++++++ > sysdeps/unix/sysv/linux/riscv/swapcontext.S | 41 ++++++++++++++++++++++ > sysdeps/unix/sysv/linux/riscv/sys/ucontext.h | 2 ++ > .../sysv/linux/riscv/sysconf-pthread_stack_min.h | 39 ++++++++++++++++++++ > sysdeps/unix/sysv/linux/riscv/sysdep.h | 1 + > sysdeps/unix/sysv/linux/riscv/ucontext_i.sym | 6 ++++ > 13 files changed, 228 insertions(+), 32 deletions(-) > create mode 100644 sysdeps/riscv/rtld-global-offsets.sym > create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/hwcap.h > create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/pthread_stack_min.h > delete mode 100644 sysdeps/unix/sysv/linux/riscv/bits/sigcontext.h > create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/sigstack.h > create mode 100644 sysdeps/unix/sysv/linux/riscv/sysconf-pthread_stack_min.h >
On Mon, Sep 13, 2021 at 12:11 PM Vineet Gupta via Libc-alpha < libc-alpha@sourceware.org> wrote: > What about gcc/binutils: sifive forks for those have quite a few > branches with rvv suffix, but it is not obvious which one pertains to > the specific version implemented in qemu above. > Binutils RVV support can be found on the RISC-V integration branch in the FSF Binutils tree: users/riscv/binutils-integration-branch. There is no usable RVV GCC port. One was started and then mostly abandoned. It still gets the occasional patch, but it should not be trusted. RVV work nowadays is happening only in clang and is available on mainline in the llvm.org git tree. Special options are required to enable it though. If you really want to try an RVV GCC port, you can find one at github.com/riscv/riscv-gnu-toolchain on the rvv-intrinsics branch. Note that the submodules are not being kept up to date, but the branch names are in the .gitmodules file, so you can use "git submodule update --remote" to get the most recent commit for them. I would however advise against trying to use this compiler for any serious work. It is buggy and out of date. Use clang instead. But since we aren't trying to put vector intrinsic calls into glibc or the kernel, all you should really need is the assembler. Jim
On Mon, Sep 13, 2021 at 09:41:13AM +0800, Vincent Chen wrote: > This patchset adds required ports to support RISC-V Vector (RVV) extension. > > Since the length of the vector register in RVV (the theoretical maximum > is 2^XLEN-1 bits) is variable, a huge and flexible space is needed to back > up all vector registers in the signal context. This patchset expands the > default SIGSTKSZ, MINSIGSTKSZ, and PTHREAD_STACK_MIN to ensure the stack > size is enough for the normal case (VLENB <= 128 bytes). Linux kernel also > places the exact minimum signal stack size in AT_MINSIGSTKSZ entry of the > auxiliary vector to inform user, so user still can know the sutible minimum > signal stack size by sysconf (_SC_MINSIGSTKSZ) if the VLENB is greater > than 128 bytes. > > In addition, according to the specification, the VCSR that combines VXRM and > VXSAT has thread storage duration, so this patchset adds the required user > context operation for it. > > Finally, the RISC-V glibc customized sigcontext.h has been removed in this > patchset. to reduce the synchronization work when new extension support is > introduced to the Linux environment. However, it may bring some backward > incompatible issues. Therefore, I sent an RFC patch > (https://sourceware.org/pipermail/libc-alpha/2020-June/115549.html) > to discuss this modification before this patchset. As I mentioned in the > RFC patch thread, I used OpenEmbeded to evaluate the impact. During the > tests, I didn't get any compiler errors. Therefore, I infer that this > modification may not cause server backward incompatible issues at this > moment. > > 1. The RISC-V V-extension draft v1.0 can be found in > https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc > 2. The associated kernel implementation can be found in > http://lists.infradead.org/pipermail/linux-riscv/2021-September/008249.html > 3. QEMU with RISC-V V-extension support can be found in > https://github.com/sifive/qemu/tree/rvv-1.0 > For the record on libc-alpha, I object to these changes. In particular, the lack of a user space API for the corresponding Linux support. More discussion on linux-riscv: https://lists.infradead.org/pipermail/linux-riscv/2021-September/thread.html#8361 > Vincent Chen (5): > RISC-V: Remove riscv-specific sigcontext.h > RISC-V: Reserve about 5K space in mcontext_t to support future ISA > expansion. > RISC-V: Save and restore VCSR when doing user context switch > RISC-V: Extend MINSIGSTKSZ and SIGSTKSZ to backup RVV registers > RISC-V: Expand PTHREAD_STACK_MIN to support RVV environment > > sysdeps/riscv/Makefile | 5 +++ > sysdeps/riscv/rtld-global-offsets.sym | 7 ++++ > sysdeps/unix/sysv/linux/riscv/bits/hwcap.h | 31 ++++++++++++++++ > .../unix/sysv/linux/riscv/bits/pthread_stack_min.h | 21 +++++++++++ > sysdeps/unix/sysv/linux/riscv/bits/sigcontext.h | 31 ---------------- > sysdeps/unix/sysv/linux/riscv/bits/sigstack.h | 32 +++++++++++++++++ > sysdeps/unix/sysv/linux/riscv/getcontext.S | 22 +++++++++++- > sysdeps/unix/sysv/linux/riscv/setcontext.S | 22 ++++++++++++ > sysdeps/unix/sysv/linux/riscv/swapcontext.S | 41 ++++++++++++++++++++++ > sysdeps/unix/sysv/linux/riscv/sys/ucontext.h | 2 ++ > .../sysv/linux/riscv/sysconf-pthread_stack_min.h | 39 ++++++++++++++++++++ > sysdeps/unix/sysv/linux/riscv/sysdep.h | 1 + > sysdeps/unix/sysv/linux/riscv/ucontext_i.sym | 6 ++++ > 13 files changed, 228 insertions(+), 32 deletions(-) > create mode 100644 sysdeps/riscv/rtld-global-offsets.sym > create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/hwcap.h > create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/pthread_stack_min.h > delete mode 100644 sysdeps/unix/sysv/linux/riscv/bits/sigcontext.h > create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/sigstack.h > create mode 100644 sysdeps/unix/sysv/linux/riscv/sysconf-pthread_stack_min.h > > -- > 2.7.4 >
On Tue, Nov 9, 2021 at 11:21 AM Darius Rad <darius@bluespec.com> wrote: > > On Mon, Sep 13, 2021 at 09:41:13AM +0800, Vincent Chen wrote: > > This patchset adds required ports to support RISC-V Vector (RVV) extension. > > > > Since the length of the vector register in RVV (the theoretical maximum > > is 2^XLEN-1 bits) is variable, a huge and flexible space is needed to back > > up all vector registers in the signal context. This patchset expands the > > default SIGSTKSZ, MINSIGSTKSZ, and PTHREAD_STACK_MIN to ensure the stack > > size is enough for the normal case (VLENB <= 128 bytes). Linux kernel also > > places the exact minimum signal stack size in AT_MINSIGSTKSZ entry of the > > auxiliary vector to inform user, so user still can know the sutible minimum > > signal stack size by sysconf (_SC_MINSIGSTKSZ) if the VLENB is greater > > than 128 bytes. > > > > In addition, according to the specification, the VCSR that combines VXRM and > > VXSAT has thread storage duration, so this patchset adds the required user > > context operation for it. > > > > Finally, the RISC-V glibc customized sigcontext.h has been removed in this > > patchset. to reduce the synchronization work when new extension support is > > introduced to the Linux environment. However, it may bring some backward > > incompatible issues. Therefore, I sent an RFC patch > > (https://sourceware.org/pipermail/libc-alpha/2020-June/115549.html) > > to discuss this modification before this patchset. As I mentioned in the > > RFC patch thread, I used OpenEmbeded to evaluate the impact. During the > > tests, I didn't get any compiler errors. Therefore, I infer that this > > modification may not cause server backward incompatible issues at this > > moment. > > > > 1. The RISC-V V-extension draft v1.0 can be found in > > https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc > > 2. The associated kernel implementation can be found in > > http://lists.infradead.org/pipermail/linux-riscv/2021-September/008249.html > > 3. QEMU with RISC-V V-extension support can be found in > > https://github.com/sifive/qemu/tree/rvv-1.0 > > > > For the record on libc-alpha, I object to these changes. In particular, > the lack of a user space API for the corresponding Linux support. More > discussion on linux-riscv: > > https://lists.infradead.org/pipermail/linux-riscv/2021-September/thread.html#8361 I do not agree with that analysis. The vector extension scales down to having potentially very little state (512 bytes on RV64) and we expect typical applications-processor implementations to land in the 512 - 2048-byte range. This matches AVX, not AMX. Furthermore, we want all implementations to take advantage of vectorized C string/memory functions without having to explicitly opt in. Not doing this would put RISC-V at a significant competitive disadvantage vs. other architectures with SIMD units. > > > > Vincent Chen (5): > > RISC-V: Remove riscv-specific sigcontext.h > > RISC-V: Reserve about 5K space in mcontext_t to support future ISA > > expansion. > > RISC-V: Save and restore VCSR when doing user context switch > > RISC-V: Extend MINSIGSTKSZ and SIGSTKSZ to backup RVV registers > > RISC-V: Expand PTHREAD_STACK_MIN to support RVV environment > > > > sysdeps/riscv/Makefile | 5 +++ > > sysdeps/riscv/rtld-global-offsets.sym | 7 ++++ > > sysdeps/unix/sysv/linux/riscv/bits/hwcap.h | 31 ++++++++++++++++ > > .../unix/sysv/linux/riscv/bits/pthread_stack_min.h | 21 +++++++++++ > > sysdeps/unix/sysv/linux/riscv/bits/sigcontext.h | 31 ---------------- > > sysdeps/unix/sysv/linux/riscv/bits/sigstack.h | 32 +++++++++++++++++ > > sysdeps/unix/sysv/linux/riscv/getcontext.S | 22 +++++++++++- > > sysdeps/unix/sysv/linux/riscv/setcontext.S | 22 ++++++++++++ > > sysdeps/unix/sysv/linux/riscv/swapcontext.S | 41 ++++++++++++++++++++++ > > sysdeps/unix/sysv/linux/riscv/sys/ucontext.h | 2 ++ > > .../sysv/linux/riscv/sysconf-pthread_stack_min.h | 39 ++++++++++++++++++++ > > sysdeps/unix/sysv/linux/riscv/sysdep.h | 1 + > > sysdeps/unix/sysv/linux/riscv/ucontext_i.sym | 6 ++++ > > 13 files changed, 228 insertions(+), 32 deletions(-) > > create mode 100644 sysdeps/riscv/rtld-global-offsets.sym > > create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/hwcap.h > > create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/pthread_stack_min.h > > delete mode 100644 sysdeps/unix/sysv/linux/riscv/bits/sigcontext.h > > create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/sigstack.h > > create mode 100644 sysdeps/unix/sysv/linux/riscv/sysconf-pthread_stack_min.h > > > > -- > > 2.7.4 > >
On Tue, Nov 09, 2021 at 11:30:49AM -0800, Andrew Waterman wrote: > On Tue, Nov 9, 2021 at 11:21 AM Darius Rad <darius@bluespec.com> wrote: > > > > On Mon, Sep 13, 2021 at 09:41:13AM +0800, Vincent Chen wrote: > > > This patchset adds required ports to support RISC-V Vector (RVV) extension. > > > > > > Since the length of the vector register in RVV (the theoretical maximum > > > is 2^XLEN-1 bits) is variable, a huge and flexible space is needed to back > > > up all vector registers in the signal context. This patchset expands the > > > default SIGSTKSZ, MINSIGSTKSZ, and PTHREAD_STACK_MIN to ensure the stack > > > size is enough for the normal case (VLENB <= 128 bytes). Linux kernel also > > > places the exact minimum signal stack size in AT_MINSIGSTKSZ entry of the > > > auxiliary vector to inform user, so user still can know the sutible minimum > > > signal stack size by sysconf (_SC_MINSIGSTKSZ) if the VLENB is greater > > > than 128 bytes. > > > > > > In addition, according to the specification, the VCSR that combines VXRM and > > > VXSAT has thread storage duration, so this patchset adds the required user > > > context operation for it. > > > > > > Finally, the RISC-V glibc customized sigcontext.h has been removed in this > > > patchset. to reduce the synchronization work when new extension support is > > > introduced to the Linux environment. However, it may bring some backward > > > incompatible issues. Therefore, I sent an RFC patch > > > (https://sourceware.org/pipermail/libc-alpha/2020-June/115549.html) > > > to discuss this modification before this patchset. As I mentioned in the > > > RFC patch thread, I used OpenEmbeded to evaluate the impact. During the > > > tests, I didn't get any compiler errors. Therefore, I infer that this > > > modification may not cause server backward incompatible issues at this > > > moment. > > > > > > 1. The RISC-V V-extension draft v1.0 can be found in > > > https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc > > > 2. The associated kernel implementation can be found in > > > http://lists.infradead.org/pipermail/linux-riscv/2021-September/008249.html > > > 3. QEMU with RISC-V V-extension support can be found in > > > https://github.com/sifive/qemu/tree/rvv-1.0 > > > > > > > For the record on libc-alpha, I object to these changes. In particular, > > the lack of a user space API for the corresponding Linux support. More > > discussion on linux-riscv: > > > > https://lists.infradead.org/pipermail/linux-riscv/2021-September/thread.html#8361 > > I do not agree with that analysis. The vector extension scales down > to having potentially very little state (512 bytes on RV64) and we > expect typical applications-processor implementations to land in the > 512 - 2048-byte range. This matches AVX, not AMX. Furthermore, we > want all implementations to take advantage of vectorized C > string/memory functions without having to explicitly opt in. Not > doing this would put RISC-V at a significant competitive disadvantage > vs. other architectures with SIMD units. > The vector extension also scales up to 256 kiB, which, for comparison sake, is considerably more than AMX. There are those that believe AVX should have had some sort of user space control [1], as well. [1] https://lore.kernel.org/lkml/87k0ntazyn.ffs@nanos.tec.linutronix.de/ I don't see how having user space control either prevents glibc from using vector by default when it is available or how it puts RISC-V at a significant competitive disadvantage.
On Tue, Nov 9, 2021 at 2:04 PM Darius Rad <darius@bluespec.com> wrote: > > On Tue, Nov 09, 2021 at 11:30:49AM -0800, Andrew Waterman wrote: > > On Tue, Nov 9, 2021 at 11:21 AM Darius Rad <darius@bluespec.com> wrote: > > > > > > On Mon, Sep 13, 2021 at 09:41:13AM +0800, Vincent Chen wrote: > > > > This patchset adds required ports to support RISC-V Vector (RVV) extension. > > > > > > > > Since the length of the vector register in RVV (the theoretical maximum > > > > is 2^XLEN-1 bits) is variable, a huge and flexible space is needed to back > > > > up all vector registers in the signal context. This patchset expands the > > > > default SIGSTKSZ, MINSIGSTKSZ, and PTHREAD_STACK_MIN to ensure the stack > > > > size is enough for the normal case (VLENB <= 128 bytes). Linux kernel also > > > > places the exact minimum signal stack size in AT_MINSIGSTKSZ entry of the > > > > auxiliary vector to inform user, so user still can know the sutible minimum > > > > signal stack size by sysconf (_SC_MINSIGSTKSZ) if the VLENB is greater > > > > than 128 bytes. > > > > > > > > In addition, according to the specification, the VCSR that combines VXRM and > > > > VXSAT has thread storage duration, so this patchset adds the required user > > > > context operation for it. > > > > > > > > Finally, the RISC-V glibc customized sigcontext.h has been removed in this > > > > patchset. to reduce the synchronization work when new extension support is > > > > introduced to the Linux environment. However, it may bring some backward > > > > incompatible issues. Therefore, I sent an RFC patch > > > > (https://sourceware.org/pipermail/libc-alpha/2020-June/115549.html) > > > > to discuss this modification before this patchset. As I mentioned in the > > > > RFC patch thread, I used OpenEmbeded to evaluate the impact. During the > > > > tests, I didn't get any compiler errors. Therefore, I infer that this > > > > modification may not cause server backward incompatible issues at this > > > > moment. > > > > > > > > 1. The RISC-V V-extension draft v1.0 can be found in > > > > https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc > > > > 2. The associated kernel implementation can be found in > > > > http://lists.infradead.org/pipermail/linux-riscv/2021-September/008249.html > > > > 3. QEMU with RISC-V V-extension support can be found in > > > > https://github.com/sifive/qemu/tree/rvv-1.0 > > > > > > > > > > For the record on libc-alpha, I object to these changes. In particular, > > > the lack of a user space API for the corresponding Linux support. More > > > discussion on linux-riscv: > > > > > > https://lists.infradead.org/pipermail/linux-riscv/2021-September/thread.html#8361 > > > > I do not agree with that analysis. The vector extension scales down > > to having potentially very little state (512 bytes on RV64) and we > > expect typical applications-processor implementations to land in the > > 512 - 2048-byte range. This matches AVX, not AMX. Furthermore, we > > want all implementations to take advantage of vectorized C > > string/memory functions without having to explicitly opt in. Not > > doing this would put RISC-V at a significant competitive disadvantage > > vs. other architectures with SIMD units. > > > > The vector extension also scales up to 256 kiB, which, for comparison sake, > is considerably more than AMX. We have good reason to believe that apps/server processors will not get anywhere near an order of magnitude of that limit, and that huge vector regfiles will be the province of HPC. > > There are those that believe AVX should have had some sort of user space > control [1], as well. > > [1] https://lore.kernel.org/lkml/87k0ntazyn.ffs@nanos.tec.linutronix.de/ > > I don't see how having user space control either prevents glibc from using > vector by default when it is available or how it puts RISC-V at a > significant competitive disadvantage. My "competitive advantage" comment was about the need to do the following (quoting from your other message): "A process (or thread) must specifically request the desire to use vector extensions (perhaps with some new arch_prctl() API)" I had assumed you meant that programmers must do this explicitly--which would clearly put RISC-V at a competitive disadvantage. If glibc initialization code makes this API call, then I withdraw my comment. (But then I question the value of the API call vs. the kernel automatically enabling the vector unit, since essentially all processes will invoke the API call anyway.)
On Tue, Nov 09, 2021 at 02:18:17PM -0800, Andrew Waterman wrote: > On Tue, Nov 9, 2021 at 2:04 PM Darius Rad <darius@bluespec.com> wrote: > > > > On Tue, Nov 09, 2021 at 11:30:49AM -0800, Andrew Waterman wrote: > > > On Tue, Nov 9, 2021 at 11:21 AM Darius Rad <darius@bluespec.com> wrote: > > > > > > > > On Mon, Sep 13, 2021 at 09:41:13AM +0800, Vincent Chen wrote: > > > > > This patchset adds required ports to support RISC-V Vector (RVV) extension. > > > > > > > > > > Since the length of the vector register in RVV (the theoretical maximum > > > > > is 2^XLEN-1 bits) is variable, a huge and flexible space is needed to back > > > > > up all vector registers in the signal context. This patchset expands the > > > > > default SIGSTKSZ, MINSIGSTKSZ, and PTHREAD_STACK_MIN to ensure the stack > > > > > size is enough for the normal case (VLENB <= 128 bytes). Linux kernel also > > > > > places the exact minimum signal stack size in AT_MINSIGSTKSZ entry of the > > > > > auxiliary vector to inform user, so user still can know the sutible minimum > > > > > signal stack size by sysconf (_SC_MINSIGSTKSZ) if the VLENB is greater > > > > > than 128 bytes. > > > > > > > > > > In addition, according to the specification, the VCSR that combines VXRM and > > > > > VXSAT has thread storage duration, so this patchset adds the required user > > > > > context operation for it. > > > > > > > > > > Finally, the RISC-V glibc customized sigcontext.h has been removed in this > > > > > patchset. to reduce the synchronization work when new extension support is > > > > > introduced to the Linux environment. However, it may bring some backward > > > > > incompatible issues. Therefore, I sent an RFC patch > > > > > (https://sourceware.org/pipermail/libc-alpha/2020-June/115549.html) > > > > > to discuss this modification before this patchset. As I mentioned in the > > > > > RFC patch thread, I used OpenEmbeded to evaluate the impact. During the > > > > > tests, I didn't get any compiler errors. Therefore, I infer that this > > > > > modification may not cause server backward incompatible issues at this > > > > > moment. > > > > > > > > > > 1. The RISC-V V-extension draft v1.0 can be found in > > > > > https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc > > > > > 2. The associated kernel implementation can be found in > > > > > http://lists.infradead.org/pipermail/linux-riscv/2021-September/008249.html > > > > > 3. QEMU with RISC-V V-extension support can be found in > > > > > https://github.com/sifive/qemu/tree/rvv-1.0 > > > > > > > > > > > > > For the record on libc-alpha, I object to these changes. In particular, > > > > the lack of a user space API for the corresponding Linux support. More > > > > discussion on linux-riscv: > > > > > > > > https://lists.infradead.org/pipermail/linux-riscv/2021-September/thread.html#8361 > > > > > > I do not agree with that analysis. The vector extension scales down > > > to having potentially very little state (512 bytes on RV64) and we > > > expect typical applications-processor implementations to land in the > > > 512 - 2048-byte range. This matches AVX, not AMX. Furthermore, we > > > want all implementations to take advantage of vectorized C > > > string/memory functions without having to explicitly opt in. Not > > > doing this would put RISC-V at a significant competitive disadvantage > > > vs. other architectures with SIMD units. > > > > > > > The vector extension also scales up to 256 kiB, which, for comparison sake, > > is considerably more than AMX. > > We have good reason to believe that apps/server processors will not > get anywhere near an order of magnitude of that limit, and that huge > vector regfiles will be the province of HPC. > > > > > There are those that believe AVX should have had some sort of user space > > control [1], as well. > > > > [1] https://lore.kernel.org/lkml/87k0ntazyn.ffs@nanos.tec.linutronix.de/ > > > > I don't see how having user space control either prevents glibc from using > > vector by default when it is available or how it puts RISC-V at a > > significant competitive disadvantage. > > My "competitive advantage" comment was about the need to do the > following (quoting from your other message): > > "A process (or thread) must specifically request the desire to use > vector extensions (perhaps with some new arch_prctl() API)" > > I had assumed you meant that programmers must do this > explicitly--which would clearly put RISC-V at a competitive > disadvantage. If glibc initialization code makes this API call, then > I withdraw my comment. (But then I question the value of the API call > vs. the kernel automatically enabling the vector unit, since > essentially all processes will invoke the API call anyway.) The benefit to having the API call is that it allows the kernel to report a failure. This is necessary now, because memory allocation for context state can fail, and in some circumstances there is no other way to report that error. It is also useful for the future, as a way for the kernel to provide a policy enforcement mechanism whereby the system administrator can control which tasks are permitted to use vector extensions.