Re: [PATCH 1/4] RISC-V: Add crypto vector implied ISA info.

On 2023/12/06 11:45, Feng Wang wrote: > Due to the crypto vector entension is depend on the Vector extension, > so the "v" info is added into implied ISA info with the corresponding > crypto vector extension. Hi Feng, It's true that vector crypto extensions are based on the vector extension but i

[committed (pre-approved)] RISC-V: Fix 'E' extension version to test

From: Tsukasa OI Commit 006e90e1 ("RISC-V: Initial RV64E and LP64E support") caused a regression (test failure) but this is caused by failing to track GCC changes in that test case (not a true GCC bug). This commit fixes the test case to track the latest GCC with 'E' e

Re: [PATCH v1 1/1] RISC-V: Initial RV64E and LP64E support

u-gcc -march=rv32e -mabi=ilp32e -S >> ../gcc/gcc/testsuite/gcc.target/riscv/predef-13.c > ../gcc/gcc/testsuite/gcc.target/riscv/predef-13.c: In function 'main': > ../gcc/gcc/testsuite/gcc.target/riscv/predef-13.c:23:2: error: #error > "__riscv_e" >23 | #error

[PATCH v1 1/1] RISC-V: Initial RV64E and LP64E support

From: Tsukasa OI Along with RV32E, RV64E is ratified. Though ILP32E and LP64E ABIs are still draft, it's worth supporting it. gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_ext_version_table): Set version to ratified 2.0. (riscv_subset_list::parse_st

[PATCH v1 0/1] RISC-V: Initial RV64E and LP64E support

his patch as non-RFC. As invoke.texi states that RVE ABIs are subject to change so I consider that the fact that the RVE ABIs are not ratified will not block merging the changes. Previous RFC PATCH: <https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633846.html> Thanks, Tsukasa Ts

[PATCH 4/4] RISC-V: Fix ICE by expansion and register coercion

From: Tsukasa OI A "prefetch" instruction on RISC-V GCC emits a machine hint instruction directly when the 'Zicbop' extension is enabled but it could cause an ICE when the address argument of __builtin_prefetch is an integral constant (such like 0 [NULL] or some other [

[PATCH 3/4] RISC-V: Add not broken RW prefetch RTL instructions without offsets

From: Tsukasa OI To prepare adding new not broken prefetch built-in functions and fixing an ICE in __builtin_prefetch, this commit adds two new instructions, each corresponding a 'Zicbop' prefetch hint instruction, but with no specifiable offset field for simplicity. This commit als

[PATCH 2/4] RISC-V: Remove broken __builtin_riscv_zicbop_cbo_prefetchi

From: Tsukasa OI __builtin_riscv_zicbop_cbo_prefetchi (corresponding "prefetch.i" instruction from the 'Zicbop' extension) is completely broken (not even functional) and should be removed rather than fixing it because it has no good way to "fix" this bui

[PATCH 1/4] RISC-V: Recategorize "prefetch" availabilities

From: Tsukasa OI Because they are for all prefetch instructions, "prefetch" fits better than "prefetchi". gcc/ChangeLog: * config/riscv/riscv-builtins.cc: Rename availabilities "prefetchi{32,64}" to "prefetch{32,64}&quo

[PATCH 0/4] RISC-V: Fix 'Zicbop'-related bugs (fix ICE and remove broken built-in)

d for fast approval to make it to GCC 14 (except renaming "prefetch" availabilities for built-in functions). Thanks, Tsukasa Tsukasa OI (4): RISC-V: Recategorize "prefetch" availabilities RISC-V: Remove broken __builtin_riscv_zicbop_cbo_prefetchi RISC-V: Add not broken RW

Re: [PATCH 0/2] RISC-V: Define not broken prefetch builtins

On 2023/09/27 6:38, Jeff Law wrote: > > > On 9/22/23 01:11, Tsukasa OI wrote: >> Hello, >> >> As I explained earlier: >> <https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626916.html>, >> the builtin function for RISC-V "__builtin_r

[RFC PATCH] RISC-V: Initial RV64E and LP64E support

From: Tsukasa OI Along with RV32E, RV64E is ratified. Though ILP32E and LP64E ABIs are still draft, it's worth supporting it. This commit should not be merged until two proposals below are going to proceed. LP64E proposal (including suggested changes): <https://github.com/riscv-non-i

Re: [PATCH] RISC-V: Prohibit combination of 'E' and 'H'

On 2023/10/22 3:04, Jeff Law wrote: > > > On 10/20/23 23:32, Tsukasa OI wrote: >> From: Tsukasa OI >> >> According to the ratified privileged specification (version 20211203), >> it says: >> >>> The hypervisor extension depends on an "I"

[PATCH] RISC-V: Prohibit combination of 'E' and 'H'

From: Tsukasa OI According to the ratified privileged specification (version 20211203), it says: > The hypervisor extension depends on an "I" base integer ISA with 32 x > registers (RV32I or RV64I), not RV32E, which has only 16 x registers. Also in the latest draft, it also

[PATCH] RISC-V: 'Zfa' extension is now ratified

From: Tsukasa OI Since this extension is ratified, it now has the version number 1.0. Reference: <https://github.com/riscv/riscv-isa-manual/pull/1096> gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_ext_version_table): Change version number of the 'Zfa

[PATCH 2/2] RISC-V: Fix ICE by expansion and register coercion

From: Tsukasa OI A "prefetch" instruction on RISC-V GCC emits a machine hint instruction directly when the 'Zicbop' extension is enabled but it could cause an ICE when the address argument of __builtin_prefetch is a integral constant (such like 0 [NULL] or some other [but pos

[PATCH 1/2] RISC-V: Define not broken prefetch builtins

From: Tsukasa OI __builtin_riscv_zicbop_cbo_prefetchi (corresponding "prefetch.i" instruction from the 'Zicbop' extension) is completely broken and new builtin is required for replacement. However, it required more than defining new builtin and/or instruction. 1. Support f

[PATCH 0/2] RISC-V: Define not broken prefetch builtins

quot;prefetch.[rw]" and I decided to make those prefetch instructions very similar to "prefetch.i". That's one of the reasons I created builtins corresponding those. Sincerely, Tsukasa Tsukasa OI (2): RISC-V: Define not broken prefetch builtins RISC-V: Fix ICE by expans

[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 insert

[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

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

[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 th

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

resents a part of behavior). riscv__si: Common (fully operate on uint32_t). On RV32, "expands" to *riscv__si. On RV64, initially expands to riscv__di_extended and extracts lower 32-bits from the int64_t result. I think this (not co

[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 th

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

represents a part of behavior). riscv__si: Common (fully operate on uint32_t). On RV32, expands to *riscv__si. On RV64, initially expands to riscv__di_extended *and* extracts lower 32-bits from the int64_t result. Sincerely, Tsukasa Tsukasa OI

[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 uns

[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

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

n a different patch set. Sincerely, Tsukasa Tsukasa OI (2): RISC-V: Make bit manipulation value / round number and shift amount types for builtins unsigned RISC-V: Update testsuite for type-changed builtins gcc/config/riscv/riscv-builtins.cc| 7 +- gcc/config/riscv/riscv

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&#x

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

V: zicond: Fix opt2 pattern") On 2023/09/06 12:07, Jeff Law wrote: > You actually don't even have to break out the common parts. The dg- > directives in an included file aren't parsed by the dg framework. Wow, that was right. It can be sometimes confusing but very usefu

[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 >

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. &

[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&#x

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

August/628867.html> note that this is not in the ChangeLog expecting the patch above applies first. Changes: v2 -> v3 * Instead of removing opt2 pattern, fix opt2 pattern: <https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629137.html> Tsukasa OI (1): RISC-V: Ad

[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. Whil

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. Whil

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&#x

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

the patch above applies first. Tsukasa OI (1): RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support gcc/common/config/riscv/riscv-common.cc | 2 + gcc/config/riscv/riscv-opts.h | 6 +++ gcc/config/riscv/riscv.cc

[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&#x

[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'D

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'

above), this small patch is splitted. Thanks, Tsukasa Tsukasa OI (1): RISC-V: Imply 'Zicsr' from 'Zcmt' gcc/common/config/riscv/riscv-common.cc | 1 + 1 file changed, 1 insertion(+) base-commit: 818cc9f2d2f3dbbd4004ff85d3125d92d1e430c9 -- 2.42.0

[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 fr

[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

[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

[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

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

commit message, reflecting the background. As a rebase result, PATCH 3/3 got nearly empty (except a test case). Thanks, Tsukasa Tsukasa OI (3): RISC-V: Add stub support for existing extensions (privileged) RISC-V: Add stub support for existing extensions (vendor) RISC-V: Add stub support for

[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

[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

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

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 P

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, t

[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, t

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

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 fi

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

n via -march (although there's a workaround using ".option" directives in the inline assembly but that's tedious). Thanks, Tsukasa On 2023/08/14 15:09, Tsukasa OI wrote: > PATCH v1: > <https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627220.html> > &

[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

[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

[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

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

7;F' implication (just I forgot to add in PATCH v1) Thanks, Tsukasa Tsukasa OI (3): RISC-V: Add stub support for existing extensions (privileged) RISC-V: Add stub support for existing extensions (vendor) RISC-V: Add stub support for existing extensions (unprivil

[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. B

[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 &

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

ompare a NaN with known binary representations with known IEEE 754 binary16/32/64's canonical NaN but it there any better way to perform this? * Any ICE possibility? For simple programs, I confirmed that no ICE occurs but I'm not sure whether this applies to other program

[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 m

[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

[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

[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

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

e GCC perspective) and not all Binutils' contents are ported. I'll submit separate patch set to port additional implications (e.g. 'M' -> 'Zmmul', 'Zve32x' -> 'Zicsr'). And despite that I implemented stub 'Zce' support, its implication

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

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

[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 b

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

align, 16 > .text > .align 2 > .globl sample > .type sample, @function > sample: > lui a5,%hi(function_to_be_called) > addia5,a5,%lo(function_to_be_called) > prefetch.i 0(a5) > tailfunction_to

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

x27;Zihintpause' extension). Please consider those patch sets and decide which to apply. Sincerely, Tsukasa Tsukasa OI (2): RISC-V: Make __builtin_riscv_pause 'Zihintpause' only RISC-V: Fix documentation of __builtin_riscv_pause gcc/common/config/riscv/riscv-common.cc

[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/exten

[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

[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'

[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/exten

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

x27; extension is absent, making a minor compatibility issue) * Because of the nature of the instrinsic, [2] is more natural ("pause" is defined in the 'Zihintpause' extension). Please consider those patch sets and decide which to apply. Sincerely, Tsukasa Tsukasa

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/exten

[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'

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

ion depending on the 'Zihintpause' extension. Other than that, I believe that this is okay and approval is appreciated. Note that because I assigned copyright of GCC contribution to FSF, I didn't attach "Signed-off-by" tag. Tell me if I need it. Thanks, Tsukasa

[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/r

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)

cv/arch-canonicalize: Likewise. Signed-off-by: Tsukasa OI --- gcc/common/config/riscv/riscv-common.cc | 2 +- gcc/config/riscv/arch-canonicalize | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/common/config/riscv/riscv-common.cc b/gcc/common/config/riscv/r

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

f change is already made in GNU Binutils and LLVM. GNU Binutils: commit c4dd8eb523fae5c9d312f4b7b21377eec66e70c3 LLVM: commit 7fe0630fcb6d52cb63463669c47f4846f7d9ccbf Tsukasa OI (1): RISC-V: Fix canonical extension order (K and J) gcc/common/config/riscv/riscv-common.cc | 2 +- gcc/config

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.

  1   2   >