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
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
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"
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
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
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
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
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
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
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 [
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
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
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
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
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
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
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
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
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
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
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'
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
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
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
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
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'
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 &
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
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
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
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
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
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>
>
&
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
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
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
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
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
permail/binutils/2022-March/120277.html>
[My copyright assignment is done on GNU Binutils]
References:
<https://github.com/riscv/riscv-isa-manual/commit/1271737463c04cacd98320d820a38f66d1c87dae>
<https://github.com/riscv/riscv-isa-manual/releases/tag/draft-20210402-1271737>
Tsukasa O
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.
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
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
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
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
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
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 "
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
&
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
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 101 matches
Mail list logo
