[COMMITTED] RISC-V: Fix typos on comments (SVE -> RVV)

From: Tsukasa OI We have the 'V' extension (RVV), not SVE from AArch64. gcc/ChangeLog: * config/riscv/riscv-vector-builtins.cc (builtin_decl, expand_builtin): Replace SVE with RVV. --- gcc/config/riscv/riscv-vector-builtins.cc | 4 ++-- 1 file changed, 2 insertions(+), 2 deleti

[PATCH] RISC-V: Add builtin .def file dependencies

From: Tsukasa OI riscv-builtins.cc includes riscv-cmo.def and riscv-scalar-crypto.def (making dependencies) but their dependencies must be explicitly defined at the configuration file, t-riscv. They were the last two .def files without correct dependency information. gcc/ChangeLog: * c

Re: [PATCH 2/2] RISC-V: Make SHA-256, SM3 and SM4 builtins operate on uint32_t

On 2023/09/12 11:44, Kito Cheng wrote: > LGTM, I think llvm and GCC are inconsistent for those intrinsics API > is really unfortunate...so really appreciate making those API align :) I guess that you mean LGTM to this patch set (given the context). If so, I will commit this patch set later. > And

[PATCH 1/2] RISC-V: Make bit manipulation value / round number and shift amount types for builtins unsigned

From: Tsukasa OI For bit manipulation operations, input(s) and the manipulated output are better to be unsigned like other target-independent builtins like __builtin_bswap32 and __builtin_popcount. Although this is not completely compatible as before (as the type changes), most code will run nor

[PATCH 2/2] RISC-V: Make SHA-256, SM3 and SM4 builtins operate on uint32_t

From: Tsukasa OI This is in parity with the LLVM commit a64b3e92c7cb ("[RISCV] Re-define sha256, Zksed, and Zksh intrinsics to use i32 types."). SHA-256, SM3 and SM4 instructions operate on 32-bit integers and upper 32-bits have no effects on RV64 (the output is sign-extended from the original 3

[PATCH 0/2] RISC-V: Change RISC-V bit manipulation / scalar crypto builtin types

Hello, My research suggests my previous RFC patchs will not break any real-world programs (as far as I could find) and I will submit this patch set (previously, two RFC patch sets) for upstream contribution. RFC PATCH 1 (combined to this):

[RFC PATCH 1/1] RISC-V: Make SHA-256, SM3 and SM4 builtins operate on uint32_t

From: Tsukasa OI This is in parity with the LLVM commit 599421ae36c3 ("[RISCV] Re-define sha256, Zksed, and Zksh intrinsics to use i32 types."). SHA-256, SM3 and SM4 instructions operate on 32-bit integers and upper 32-bits have no effects on RV64 (the output is sign-extended from the original 3

[RFC PATCH 0/1] RISC-V: Make SHA-256, SM3 and SM4 builtins operate on uint32_t

Hi, This is built on another RFC PATCH "RISC-V: Change RISC-V bit manipulation / scalar crypto builtin types" and changes SHA-256, SM3 and SM4 intrinsics operate on uint32_t, not on XLEN-bit wide integers. This is in parity with the LLVM commit 599421ae36c3 ("[RISCV] Re-define sha256, Zksed, and

[RFC PATCH 2/2] RISC-V: Update testsuite for type-changed builtins

From: Tsukasa OI This commit replaces the type of the builtin used in the testsuite. Even without this commit, it won't cause any test failures but changed so that no confusion occurs. gcc/testsuite/ChangeLog: * gcc.target/riscv/zbc32.c: Make signed type to unsigned. * gcc.targ

[RFC PATCH 1/2] RISC-V: Make bit manipulation value / round number and shift amount types for builtins unsigned

From: Tsukasa OI For bit manipulation operations, inputs and the manipulated output are better to be unsigned like other target-independent builtins like __builtin_bswap32 and __builtin_popcount. Although this is not completely compatible as before (as the type changes), most code will run norma

[RFC PATCH 0/2] RISC-V: Change RISC-V bit manipulation / scalar crypto builtin types

Hello, Many RISC-V builtins operate in signed integer types but in many cases, they are better to be unsigned. There are a few reasons to do that: 1. Being more natural For bit manipulation operations, the direct input and the result should have an unsigned type. e.g. __builtin_bswa

Re: [PATCH v3] RISC-V:Optimize the MASK opt generation

Hi, I will need to notify you that x_riscv_xventana_subext, MASK_XVENTANACONDOPS and TARGET_XVENTANACONDOPS are added (I think you want to rewrite those definitions like the rest). Also, be careful not to remove TARGET_ZICOND_LIKE. Thanks, Tsukasa On 2023/09/06 11:02, Feng Wang wrote: > This pa

Re: [PATCH 3/5] RISC-V: Add Types to Un-Typed Zicond Instructions

On 2023/09/07 2:50, Edwin Lu wrote: > This patch creates a new "zicond" type and updates all zicond instructions > with that type. > > gcc/ChangeLog: > > * config/riscv/riscv.md: Add "zicond" type > * config/riscv/zicond.md: Update types > > Signed-off-by: Edwin Lu > --- > gcc/conf

[PATCH v4 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

From: Tsukasa OI 'XVentanaCondOps' is a vendor extension from Ventana Micro Systems containing two instructions for conditional move and will be supported on their Veyron V1 CPU. And most notably (for historical reasons), 'XVentanaCondOps' and the standard 'Zicond' extension are functionally equ

[PATCH v4 0/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

PATCH v1: PATCH v2: PATCH v3: Changes: v1 -> v2 * Removed bogus opt2 pattern as pointed o

[COMMITTED] RISC-V: typo: add closing paren to a comment

From: Tsukasa OI gcc/ChangeLog: * config/riscv/zicond.md: Add closing parent to a comment. --- gcc/config/riscv/zicond.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/riscv/zicond.md b/gcc/config/riscv/zicond.md index 1721e1011ea8..c28bee5d5709 100644 -

Re: [PATCH v3 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

On 2023/09/06 9:17, Jeff Law wrote: > > > On 9/5/23 06:10, Tsukasa OI wrote: >> From: Tsukasa OI >> >> 'XVentanaCondOps' is a vendor extension from Ventana Micro Systems >> containing two instructions for conditional move and will be supported on >> their Veyron V1 CPU. >> >> And most notably (f

Re: [PATCH v2] RISC-V: Fix Zicond ICE on large constants

On 2023/09/06 10:22, Jeff Law wrote: > > > On 9/5/23 06:08, Tsukasa OI wrote: >> From: Tsukasa OI >> >> Large constant cons and/or alt will trigger ICEs building GCC target >> libraries (libgomp and libatomic) when the 'Zicond' extension is enabled. >> >> For instance, zicond-ice-2.c (new test c

[PATCH v3 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

From: Tsukasa OI 'XVentanaCondOps' is a vendor extension from Ventana Micro Systems containing two instructions for conditional move and will be supported on their Veyron V1 CPU. And most notably (for historical reasons), 'XVentanaCondOps' and the standard 'Zicond' extension are functionally equ

[PATCH v3 0/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

PATCH v1: PATCH v2: Changes: v1 -> v2 * Removed bogus opt2 pattern as pointed out in:

[PATCH v2] RISC-V: Fix Zicond ICE on large constants

From: Tsukasa OI Large constant cons and/or alt will trigger ICEs building GCC target libraries (libgomp and libatomic) when the 'Zicond' extension is enabled. For instance, zicond-ice-2.c (new test case in this commit) will cause an ICE when SOME_NUMBER is 0x1000 or larger. While opposite numb

Re: [PATCH] RISC-V: Fix Zicond ICE on large constants

On 2023/09/05 14:27, Jeff Law wrote: > > > On 9/4/23 00:45, Kito Cheng wrote: >> Maybe move the check logic a bit forward? My thought is the logic is >> already specialized into a few catalogs, (imm, imm), (imm, reg), (reg, >> reg)... and the logic you put is already in (imm, reg), but it should

Re: [PATCH v2] RISC-V: zicond: Fix opt2 pattern

Sorry, I want to directly reply to Jeff but I couldn't because I haven't subscribed to gcc-patches and Jeff's recent reply hasn't archived yet. Bug confirmed for me. I tried the full test with following configuration (I found another bug [ICE] as I submitted a quick fix while testing this and req

[PATCH] RISC-V: Fix Zicond ICE on large constants

From: Tsukasa OI Large constant cons and/or alt will trigger ICEs building GCC target libraries (libgomp and libatomic) when the 'Zicond' extension is enabled. For instance, zicond-ice-2.c (new test case in this commit) will cause an ICE when SOME_NUMBER is 0x1000 or larger. While opposite numb

Re: [PATCH 1/1] RISC-V: Imply 'Zicsr' from 'Zcmt'

On 2023/08/31 18:10, Kito Cheng wrote: > Hi Tsukasa: > > I guess you might did something wrong during commit this patch and > "RISC-V: Add stub support for existing extensions" > > https://github.com/gcc-mirror/gcc/commit/f30d6a48635b5b180e46c51138d0938d33abd942 > It's fine. That patch was a p

[RFC PATCH v2 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

From: Tsukasa OI 'XVentanaCondOps' is a vendor extension from Ventana Micro Systems containing two instructions for conditional move and will be supported on their Veyron V1 CPU. And most notably (for historical reasons), 'XVentanaCondOps' and the standard 'Zicond' extension are functionally equ

[RFC PATCH v2 0/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

PATCH v1: Changes: v1 -> v2 * Removed bogus opt2 pattern as pointed out in: note that this is not in the ChangeLog expecting the patch above applies

[RFC PATCH] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

From: Tsukasa OI 'XVentanaCondOps' is a vendor extension from Ventana Micro Systems containing two instructions for conditional move and will be supported on their Veyron V1 CPU. And most notably (for historical reasons), 'XVentanaCondOps' and the standard 'Zicond' extension are functionally equ

[COMMITTED] MAINTAINERS: Add myself to write after approval

From: Tsukasa OI ChangeLog: * MAINTAINERS: Add myself. --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4e706df65226..35f00beebff2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -592,6 +592,7 @@ Carlos O'Donell

Re: [PATCH 1/1] RISC-V: Imply 'Zicsr' from 'Zcmt'

gcc.gnu.org/gitwrite.html#authenticated , and you can add me > to the cc list as your sponsor. > > > > On Tue, Aug 29, 2023 at 11:42 AM Tsukasa OI via Gcc-patches > wrote: >> >> From: Tsukasa OI >> >> As the specification states, the 'Zcmt' extensi

[PATCH 0/1] RISC-V: Imply 'Zicsr' from 'Zcmt'

This is a subset of my patch set "RISC-V: Add stub support for existing extensions" for faster review. Since 'Zcmt' requires 'Zicsr' (and this is a bug unlike other changes in the patch set above), this small patch is splitted. T

[PATCH 1/1] RISC-V: Imply 'Zicsr' from 'Zcmt'

From: Tsukasa OI As the specification states, the 'Zcmt' extension depends on the 'Zca' and 'Zicsr' extensions. This commit reflects this implication. gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_implied_info): Add implication from 'Zcmt' to 'Zicsr'. --- gcc/com

[PATCH v3 3/3] RISC-V: Add stub support for existing extensions (unprivileged)

From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the assembler). To avoid compilation errors on shar

[PATCH v3 2/3] RISC-V: Add stub support for existing extensions (vendor)

From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the assembler). To avoid compilation errors on shar

[PATCH v3 1/3] RISC-V: Add stub support for existing extensions (privileged)

From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the assembler). To avoid compilation errors on shar

[PATCH v3 0/3] RISC-V: Add stub support for existing extensions

PATCH v1: PATCH v2: Changes: v1 -> v2 (only in PATCH 3/3) == Removed: 'Zvkn' -> 'Zvknha' implication (not to cause test fail

[PATCH] RISC-V: Make arch-24.c to test "success" case

From: Tsukasa OI arch-24.c and arch-25.c are exactly the same and redundant. The author suspects that the original author intended to test two base ISAs (RV32I and RV64I) so this commit changes arch-24.c to test that RV32I+Zcf does not cause any errors. gcc/testsuite/ChangeLog: * gcc.t

[PATCH v2] RISC-V: Make PR 102957 tests more comprehensive

From: Tsukasa OI Commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions and commit 6f709f79c915a ("[committed] [RISC-V] Fix expected diagnostic messages in testsuite") "fixed" test failures caused by that change (on pr102957.c, b

Re: [PATCH v2 3/3] RISC-V: Add stub support for existing extensions (unprivileged)

On 2023/08/29 10:42, Jeff Law wrote: > > > On 8/14/23 00:09, Tsukasa OI wrote: >> From: Tsukasa OI >> >> After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown >> extensions") changed how do we handle unknown extensions, we have no >> guarantee that we can share the same archite

Re: [RFC PATCH 2/2] RISC-V: Fix documentation of __builtin_riscv_pause

On 2023/08/29 8:09, Hans-Peter Nilsson wrote: > On Mon, 28 Aug 2023, Jeff Law via Gcc-patches wrote: >> >> >> On 8/9/23 00:11, Tsukasa OI via Gcc-patches wrote: >>> From: Tsukasa OI >>> >>> This built-in does not imply the 'Xgnuzihintpauses

Re: [PATCH] RISC-V: Revive test case PR 102957

On 2023/08/29 7:01, Jeff Law wrote: > > > On 8/11/23 08:29, Tsukasa OI wrote: >> On 2023/08/11 23:15, Jeff Law wrote: > >>> >> >> Originally, it tested that a two letter extension ('Zb') is accepted by >> GCC (because the background of PR 102957 was GCC assumed multi-letter >> 'Z' extensions are

Re: [PATCH 1/1] RISC-V: Make "prefetch.i" built-in usable

On 2023/08/29 6:20, Jeff Law wrote: > > > On 8/9/23 21:10, Tsukasa OI via Gcc-patches wrote: >> From: Tsukasa OI >> >> The "__builtin_riscv_zicbop_cbo_prefetchi" built-in function was terribly >> broken so that practically unusable.  It emitted "

Re: [RFC PATCH 1/2] RISC-V: __builtin_riscv_pause for all environment

On 2023/08/29 6:12, Jeff Law wrote: > > > On 8/9/23 00:11, Tsukasa OI via Gcc-patches wrote: >> From: Tsukasa OI >> >> The "pause" RISC-V hint instruction requires the 'Zihintpause' extension >> (in the assembler).  However, GCC emits

[PATCH 2/2] RISC-V: Add quotes to #error messages (all)

From: Tsukasa OI In commit 1aaf3a64e92a ("[PATCH] RISC-V: Deduplicate #error messages in testsuite"), the author made a mistake to miss the test after adding quotes around extension names. To avoid future errors and for consistency with other #error uses in the RISC-V testsuite, this commit quot

[PATCH 1/2] RISC-V: Add quotes to #error messages

From: Tsukasa OI In commit 1aaf3a64e92a ("[PATCH] RISC-V: Deduplicate #error messages in testsuite"), the author made a mistake to miss the test after adding quotes around extension names. To avoid future errors and for consistency with other #error uses in the RISC-V testsuite, this commit quot

Re: [2/2] RISC-V: Constant FP Optimization with 'Zfa'

On 2023/08/15 12:38, Tsukasa OI wrote: > On 2023/08/14 21:51, Jin Ma wrote: >> Hi Tsukasa, >> What a coincidence, I also implemented zfa extension, which also includes >> fli related instructions :) > > Hi, I'm glad to know that someone is working on this extension more > comprehensively (espec

Re: [2/2] RISC-V: Constant FP Optimization with 'Zfa'

On 2023/08/14 21:51, Jin Ma wrote: > Hi Tsukasa, > What a coincidence, I also implemented zfa extension, which also includes > fli related instructions :) Hi, I'm glad to know that someone is working on this extension more comprehensively (especially when "someone" is an experienced GCC contrib

Re: [PATCH 0/2] RISC-V: Constant FP Optimization with 'Zfa'

Oh my, I forgot to change the subject of PATCH 0/2. That should have been "RISC-V: Constant FP Optimization with 'Zfa'", the same subject as PATCH 2/2. Sorry for confusion! On 2023/08/14 14:32, Tsukasa OI wrote: > Hello, > > and... I think this might be my first *large* patch set for GCC > contr

Re: [PATCH v2 0/3] RISC-V: Add stub support for existing extensions

Hi, I'll explain a little more background. A major case which this patch set will be required is when a developer use inline assembly for instructions not yet natively supported by GCC or will not be supported as intrinsics. On such cases, GCC should at least accept corresponding extension via -

[PATCH v2 2/3] RISC-V: Add stub support for existing extensions (vendor)

From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the assembler). To avoid compilation errors on shar

[PATCH v2 1/3] RISC-V: Add stub support for existing extensions (privileged)

From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the assembler). To avoid compilation errors on shar

[PATCH v2 3/3] RISC-V: Add stub support for existing extensions (unprivileged)

From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the assembler). To avoid compilation errors on shar

[PATCH v2 0/3] RISC-V: Add stub support for existing extensions

PATCH v1: Changes: v1 -> v2 (only in PATCH 3/3) == Removed: 'Zvkn' -> 'Zvknha' implication (not to cause test failure) Added: 'Zfa' -> 'F' implication (just I forgot to add in PATCH v1) Th

[PATCH 2/2] RISC-V: Constant FP Optimization with 'Zfa'

From: Tsukasa OI This commit implements an optimization for assignments from a FP constant to a FP register using a FLI instruction from the 'Zfa' extension. To this purpose, it adds the constraint "H" and adds hardfloat move instructions a "H -> f" variant. Because FLI instruction constraint i

[PATCH 1/2] RISC-V: Add support for the 'Zfa' extension

From: Tsukasa OI This commit adds support for the 'Zfa' extension containing additional floating point instructions, version 0.1 (stable and approved). gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_implied_info): Add implication 'Zfa' -> 'F'. (riscv_ext_ver

[PATCH 0/2] RISC-V: Make "prefetch.i" built-in usable

Hello, and... I think this might be my first *large* patch set for GCC contribution and definitely the first one to touch the machine description. So, please review it carefully. Background === This patch set adds an optimization to FP constant initialization using a FLI instruction, w

[PATCH] RISC-V: Deduplicate #error messages in testsuite

From: Tsukasa OI "#error Feature macro not defined" is required to test the existence of an extension through the preprocessor. However, multiple occurrence of the exact same error message will confuse the developer once an error is encountered. This commit replaces such error messages to "#err

[PATCH 2/3] RISC-V: Add stub support for existing extensions (vendor)

From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the assembler). To avoid compilation errors on shar

[PATCH 3/3] RISC-V: Add stub support for existing extensions (unprivileged)

From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the assembler). To avoid compilation errors on shar

[PATCH 1/3] RISC-V: Add stub support for existing extensions (privileged)

From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the assembler). To avoid compilation errors on shar

[PATCH 0/3] RISC-V: Add stub support for existing extensions

Hello, After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the assembler). To avoid compilation errors on shared Assemble

Re: [RFC PATCH 0/2] RISC-V: __builtin_riscv_pause for all environment

On 2023/08/12 8:30, Jeff Law wrote: > > > On 8/9/23 16:39, Tsukasa OI wrote: >> On 2023/08/10 5:05, Jeff Law wrote: > >>> I'd tend to think we do not want to expose the intrinsic unless the >>> right extensions are enabled -- even though the encoding is a no-op and >>> we could emit it as a .ins

Re: [PATCH] RISC-V: Revive test case PR 102957

On 2023/08/11 23:15, Jeff Law wrote: > > > On 8/11/23 03:11, Tsukasa OI via Gcc-patches wrote: >> From: Tsukasa OI >> >> Commit c283c4774d1c ("RISC-V: Throw compilation error for unknown >> extensions") changed how do we handle unknown extensions and

[PATCH] RISC-V: Revive test case PR 102957

From: Tsukasa OI Commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions and commit 6f709f79c915a ("[committed] [RISC-V] Fix expected diagnostic messages in testsuite") "fixed" test failures caused by that change (on pr102957.c, b

[PATCH 1/1] RISC-V: Make "prefetch.i" built-in usable

From: Tsukasa OI The "__builtin_riscv_zicbop_cbo_prefetchi" built-in function was terribly broken so that practically unusable. It emitted "prefetch.i" but with no meaningful arguments. Though incompatible, this commit completely changes the function prototype of this built-in and makes it usab

[PATCH 0/1] RISC-V: Make "prefetch.i" built-in usable

Hello, I found that a built-in function "__builtin_riscv_zicbop_cbo_prefetchi" is terribly broken so that this is practically unusable. It emits the "prefetch.i" machine instruction HINT but with no usable arguments. Contents of a.c: > void function_to_be_called(void); > > void sample(void) >

[RFC PATCH 0/2] RISC-V: Make __builtin_riscv_pause 'Zihintpause' only

**WARNING** Following patch sets are exclusive: 1. [RFC PATCH v2] RISC-V: __builtin_riscv_pause for all environment 2. [RFC PATCH] RISC-V: Make __builtin_riscv_pause 'Zihintpause' only (this) See for the background of this pat

[RFC PATCH 2/2] RISC-V: Fix documentation of __builtin_riscv_pause

From: Tsukasa OI This built-in does not imply the 'Xgnuzihintpausestate' extension. It does not change architectural state (because all HINTs are prohibited from doing that). gcc/ChangeLog: * doc/extend.texi: Fix the description of __builtin_riscv_pause. --- gcc/doc/extend.texi | 6 +++

[RFC PATCH 1/2] RISC-V: Make __builtin_riscv_pause 'Zihintpause' only

From: Tsukasa OI The "pause" RISC-V hint instruction requires the 'Zihintpause' extension (in the assembler). However, GCC emits "pause" unconditionally, making an assembler error while compiling code with __builtin_riscv_pause while the 'Zihintpause' extension disabled. Despite that the "pause

[RFC PATCH v2 1/2] RISC-V: __builtin_riscv_pause for all environment

From: Tsukasa OI The "pause" RISC-V hint instruction requires the 'Zihintpause' extension (in the assembler). However, GCC emits "pause" unconditionally, making an assembler error while compiling code with __builtin_riscv_pause while the 'Zihintpause' extension disabled. However, the "pause" in

[RFC PATCH v2 2/2] RISC-V: Fix documentation of __builtin_riscv_pause

From: Tsukasa OI This built-in does not imply the 'Xgnuzihintpausestate' extension. It does not change architectural state (because all HINTs are prohibited from doing that). gcc/ChangeLog: * doc/extend.texi: Fix the description of __builtin_riscv_pause. --- gcc/doc/extend.texi | 6 +++

[RFC PATCH v2 0/2] RISC-V: __builtin_riscv_pause for all environment

**WARNING** Following patch sets are exclusive: 1. [RFC PATCH v2] RISC-V: __builtin_riscv_pause for all environment (this) 2. [RFC PATCH] RISC-V: Make __builtin_riscv_pause 'Zihintpause' only See for the background of this pat

Re: [RFC PATCH 0/2] RISC-V: __builtin_riscv_pause for all environment

On 2023/08/10 5:05, Jeff Law wrote: > > > On 8/9/23 00:11, Tsukasa OI via Gcc-patches wrote: >> Hello, >> >> I found that a built-in function "__builtin_riscv_pause" is not usable >> unless we enable the 'Zihintpause' extension explicitly (st

[RFC PATCH 2/2] RISC-V: Fix documentation of __builtin_riscv_pause

From: Tsukasa OI This built-in does not imply the 'Xgnuzihintpausestate' extension. It does not change architectural state (because all HINTs are prohibited from doing that). gcc/ChangeLog: * doc/extend.texi: Fix the description of __builtin_riscv_pause. --- gcc/doc/extend.texi | 6 +++

[RFC PATCH 1/2] RISC-V: __builtin_riscv_pause for all environment

From: Tsukasa OI The "pause" RISC-V hint instruction requires the 'Zihintpause' extension (in the assembler). However, GCC emits "pause" unconditionally, making an assembler error while compiling code with __builtin_riscv_pause while the 'Zihintpause' extension disabled. However, the "pause" in

[RFC PATCH 0/2] RISC-V: __builtin_riscv_pause for all environment

Hello, I found that a built-in function "__builtin_riscv_pause" is not usable unless we enable the 'Zihintpause' extension explicitly (still, this built-in exists EVEN IF the 'Zihintpause' extension is disabled). Contents of a.c: > void sample(void) > { > __builtin_riscv_pause(); > } Compi

[PATCH] RISC-V: Remove non-existing 'Zve32d' extension

From: Tsukasa OI Since this extension does not exist, this commit prunes this from the defined extension version table. gcc/ChangeLog: * common/config/riscv/riscv-common.cc(riscv_ext_version_table): Remove 'Zve32d' from the version list. --- gcc/common/config/riscv/riscv-common

Re: [PATCH 1/1] RISC-V: Fix canonical extension order (K and J)

On 2022/05/19 12:40, Nelson Chu wrote: > Seems like gcc and llvm have already committed this patch, so LGTM, committed. Sorry, the same change is applied to LLVM but not yet on GCC (because I forgot to add "Signed-off-by" line). I sent PATCH v2 to gcc-patches today so that would be okay. On PATC

[PATCH v2 1/1] RISC-V: Fix canonical extension order (K and J)

This commit fixes canonical extension order to follow the RISC-V ISA Manual draft-20210402-1271737 or later. gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_supported_std_ext): Fix "K" extension prefix to be placed before "J". * config/riscv/arch-canonicalize:

[PATCH v2 0/1] RISC-V: Fix canonical extension order (K and J)

PATCH v1: Changes between v1 and v2: - Added Signed-off-by line (I didn't notice that this is required) - Applied the same change to Python script: gcc/config/riscv/arch-canonicalize Note that this kind of change is alread

Re: [PATCH 1/1] RISC-V: Fix canonical extension order (K and J)

your intentions and details: do we need to place Z[CH]* extensions without single-letter extension [CH] after all existing ones (like Zv*)? Or, Z[CH]* extensions without single-letter extension [CH] have no constraints as long as all Z* extensions are grouped together? > > On Sat, Apr 2

[PATCH 1/1] RISC-V: Fix canonical extension order (K and J)

This commit fixes canonical extension order to follow the RISC-V ISA Manual draft-20210402-1271737 or later. gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_supported_std_ext): Fix "K" extension prefix to be placed before "J". --- gcc/common/config/riscv/riscv-common.

[PATCH 0/1] RISC-V: Fix canonical extension order (K and J)

**note** My copyright assignment to FSF is not yet started (will start just after sending this patch). Please take care of the assignment status. This patch fixes RISC-V's canonical extension order... from: "J" -> "K" to : "K" -> "J" as per the RISC-V ISA Manual draft-20210402-1271737 or late