There are some xtheadvector instructions that differ from RVV1.0
apart from simply adding "th." prefix. For example, RVV1.0
load/store instructions will have SEW while xtheadvector not;
RVV1.0 will have "o" for indexed-ordered store instructions while
xtheadvecotr not; xtheadvector and RVV1.0 have
For th.vmadc/th.vmsbc as well as narrowing arithmetic instructions
and floating-point compare instructions, an illegal instruction
exception will be raised if the destination vector register overlaps
a source vector register group.
To handle this issue, we use "group_overlap" and "enabled" attribu
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, December 29, 2023 6:24 PM
> To: Di Zhao OS
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] aarch64: add 'AARCH64_EXTRA_TUNE_FULLY_PIPELINED_FMA'
>
> Di Zhao OS writes:
> > This patch adds a new tuning option
> > 'AARCH
LGTM.
juzhe.zh...@rivai.ai
From: Feng Wang
Date: 2024-01-03 13:21
To: gcc-patches
CC: kito.cheng; jeffreyalaw; juzhe.zhong; Feng Wang
Subject: [PATCH v7 2/2] RISC-V: Add crypto vector api-testing cases.
Patch v7: Add newline at the end of file.
Patch v6: Move intrinsic tests into rvv/base.
Pat
This patch is to handle the differences in instruction generation
between Vector and XTheadVector. In this version, we only support
partial xtheadvector instructions that leverage directly from current
RVV1.0 with simple adding "th." prefix. For different name xtheadvector
instructions but share sa
This patch adds th. prefix to all XTheadVector instructions by
implementing new assembly output functions. We only check the
prefix is 'v', so that no extra attribute is needed.
gcc/ChangeLog:
* config/riscv/riscv-protos.h (riscv_asm_output_opcode):
New function to add assembler i
On 21/12/2023 22:55, Jonathan Wakely wrote:
I think this should wait for the next stage 1. It's a big patch
affecting the default -std mode (not just experimental C++20/23/26
material), and was first posted after the end of stage 1.
The idea of this patch was in the air far before it but I agre
Patch v7: Add newline at the end of file.
Patch v6: Move intrinsic tests into rvv/base.
Patch v5: Rebase
Patch v4: Add some RV32 vx constraint testcase.
Patch v3: Refine crypto vector api-testing cases.
Patch v2: Update march info according to the change of riscv-common.c
This patch add crypto vec
On Tue, 12 Dec 2023, Maciej W. Rozycki wrote:
> Hi,
>
> This patch quasi-series makes it possible for individual test cases
> identified as being slow to request more time via the GCC test harness by
> providing a test execution timeout factor, applied to the tool execution
> timeout set glob
On 10/24/23 12:49, Richard Sandiford wrote:
This patch adds a combine pass that runs late in the pipeline.
There are two instances: one between combine and split1, and one
after postreload.
So have you done any investigation on cases caught by your new pass
between combine and split1 to chara
Hi Andrew:
That's kinda compromise and trade off on the t-head vector stuffs, we
would like to accept that, but without disturbing the vector 1.0
implementation too much, t-head vector is transitional product and it
will freeze/stop there forever without extending new stuffs like
vector bfloat and
On Tue, Jan 2, 2024 at 7:26 PM juzhe.zh...@rivai.ai
wrote:
>
> No. It will need to change all patterns in vector.md.
> It's a nightmare.
>
> You should note I will refine vector.md in GCC-15, mixing theadvector things
> make me impossible to maintain
> RVV1.0.
Then we should not support theadvec
No. It will need to change all patterns in vector.md.
It's a nightmare.
You should note I will refine vector.md in GCC-15, mixing theadvector things
make me impossible to maintain
RVV1.0.
juzhe.zh...@rivai.ai
From: Andrew Pinski
Date: 2024-01-03 11:19
To: juzhe.zh...@rivai.ai
CC: jeffreyalaw
On Tue, Jan 2, 2024 at 7:07 PM juzhe.zh...@rivai.ai
wrote:
>
> We have no choice. You should know theadvector is totally unrelated with
> RVV1.0 standard ISA.
>
> Adding `%^' which missing totally unrelated ISA makes no sens to me.
No, it implements it in a different way.
Basically all of the pa
Got it.
Jeff Law 于 2024年1月3日周三 上午11:05写道：
>
>
> On 1/2/24 13:17, trdth...@gmail.com wrote:
> > From: trdthg
> >
> > This patch supports Zacas extension.
> > It includes instruction's machine description and built-in functions.
> >
> > gcc/ChangeLog:
> >
> > * common/config/riscv/riscv-com
> diff --git a/gcc/config/riscv/riscv_th_vector.h
> b/gcc/config/riscv/riscv_th_vector.h
> new file mode 100644
> index 000..6f47e0c90a4
> --- /dev/null
> +++ b/gcc/config/riscv/riscv_th_vector.h
> @@ -0,0 +1,49 @@
> +/* RISC-V 'XTheadVector' Extension intrinsics include file.
> + Copyri
We have no choice. You should know theadvector is totally unrelated with RVV1.0
standard ISA.
Adding `%^' which missing totally unrelated ISA makes no sens to me.
juzhe.zh...@rivai.ai
From: Andrew Pinski
Date: 2024-01-03 10:54
To: 钟居哲
CC: Jeff Law; cooper.joshua; gcc-patches; jim.wilson.gcc;
On 1/2/24 13:17, trdth...@gmail.com wrote:
From: trdthg
This patch supports Zacas extension.
It includes instruction's machine description and built-in functions.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_implied_info): Add zacas extensions.
(riscv
Please move those code logic to thead.cc, e.g.
if (TARGET_XTHEADVECTOR)
return th_asm_output_opcode (asm_out_file, p);
And then implement th_asm_output_opcode in thead.cc.
On Wed, Jan 3, 2024 at 10:39 AM Jun Sha (Joshua)
wrote:
>
> There are some xtheadvector instructions that differ from RV
On Mon, Jan 1, 2024 at 2:59 PM 钟居哲 wrote:
>
> This is Ok from my side.
> But before commit this patch, I think we need this patch first:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641533.html
>
> I will be back to work so I will take a look at other patches today.
Note I hate it.
There are some xtheadvector instructions that differ from RVV1.0
apart from simply adding "th." prefix. For example, RVV1.0
load/store instructions will have SEW while xtheadvector not;
RVV1.0 will have "o" for indexed-ordered store instructions while
xtheadvecotr not; xtheadvector and RVV1.0 have
For th.vmadc/th.vmsbc as well as narrowing arithmetic instructions
and floating-point compare instructions, an illegal instruction
exception will be raised if the destination vector register overlaps
a source vector register group.
To handle this issue, we use "group_overlap" and "enabled" attribu
At present, Evaluation of both `has_lse2(hwcap)' and
`has_lse128(hwcap)' may require issuing an `mrs' instruction to query
a system register. This instruction, when issued from user-space
results in a trap by the kernel which then returns the value read in
by the system register. Given the undesi
The introduction of further architectural-feature dependent ifuncs
for AArch64 makes hard-coding ifunc `_i' suffixes to functions
cumbersome to work with. It is awkward to remember which ifunc maps
onto which arch feature and makes the code harder to maintain when new
ifuncs are added and their su
The armv9.4-a architectural revision adds three new atomic operations
associated with the LSE128 feature:
* LDCLRP - Atomic AND NOT (bitclear) of a location with 128-bit
value held in a pair of registers, with original data loaded into
the same 2 registers.
* LDSETP - Atomic OR (bitset) of
v3 updates:
1. In the absence of the `HWCAP_LSE128' feature bit in the current
Linux Kernel release, the feature check continues to rely on a user
space-issued `mrs' instruction. Since the the ABI for exporting
the AArch64 CPU ID/feature registers to userspace relies on
FEAT_IDST [
Patch v6: Move intrinsic tests into rvv/base.
Patch v5: Rebase
Patch v4: Add some RV32 vx constraint testcase.
Patch v3: Refine crypto vector api-testing cases.
Patch v2: Update march info according to the change of riscv-common.c
This patch add crypto vector api-testing cases based on
https://git
\ No newline at end of file
All files Need newline.
juzhe.zh...@rivai.ai
From: Feng Wang
Date: 2024-01-03 09:01
To: gcc-patches
CC: kito.cheng; jeffreyalaw; juzhe.zhong; Feng Wang
Subject: [PATCH v6 2/2] RISC-V: Add crypto vector api-testing cases.
Patch v6: Move intrinsic tests into rvv/base.
On 2024/1/2 11:57, Vaseeharan Vinayagamoorthy wrote:
Hi Lipeng,
It looks like your draft patch to fix the builds for arm-none-eabi target is
not merged yet, because our arm-none-eabi builds are still broken. Are you
waiting for additional information, or would you be able to fix this issue?
On Tue, 2 Jan 2024, David Malcolm wrote:
> > > +#print(f'{url_suffix=} {index_text=}')
> >
> > Various commented-out or "if 0" debugging code like this should probably
> > be removed (or made into an actual runtime conditional if desired).
>
> I've removed them all.
There are still a f
2024-01-03 00:32 Jeff Law wrote:
>
>
>On 1/1/24 19:25, Feng Wang wrote:
>> gcc/ChangeLog:
>> * config/riscv/vector-crypto.md: Modify copyright year.
>> ---
>> gcc/config/riscv/vector-crypto.md | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gcc/conf
On Wed, 2023-12-20 at 00:24 +, Joseph Myers wrote:
Thanks for the review.
> On Thu, 14 Dec 2023, David Malcolm wrote:
>
> > diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
> > index 26a7e9c35070..9a394b3e2c77 100644
> > --- a/gcc/doc/sourcebuild.texi
> > +++ b/gcc/doc/source
Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor:
On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote:
From: Björn Schäpers
Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except
that libraries loaded after the backtrace_initialize are not handled.
But as far as I can see tha
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639082.html.
On Sun, Dec 03, 2023 at 11:46:36PM +1100, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> The TYPE_DECL_SUPPRESS_DEBUG and DECL_EXTERNAL flags use the same
> u
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638089.html.
On Fri, Nov 24, 2023 at 10:32:13PM +1100, Nathaniel Shead wrote:
> On Thu, Nov 23, 2023 at 12:11:58PM -0500, Nathan Sidwell wrote:
> > On 11/14/23 01:24, Nathaniel Shead wrote:
> > > I'll also note that the comments abov
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637768.html.
On Sat, Dec 16, 2023 at 09:50:10PM +1100, Nathaniel Shead wrote:
> Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637768.html.
> (I've changed the summary message a little from that email but the patch
(Whoops, forgot the '[PATCH]', fixed the subject in email.)
On Wed, Jan 03, 2024 at 09:40:55AM +1100, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> Static data members marked 'inline' should be emitted in TUs where they
> are ODR-used.
Andrew Pinski writes:
> Ccmp is not used if the result of the and/ior is used by both
> a GIMPLE_COND and a GIMPLE_ASSIGN. This improves the code generation
> here by using ccmp in this case.
> Two changes is required, first we need to allow the outer statement's
> result be used more than once.
>
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
The attached testcase Patrick found in PR c++/112899 ICEs because it is
attempting to write a variable initializer that is no longer in the
static_aggregates map.
The issue is that, for non-header modules, the loop in
c_pa
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
Static data members marked 'inline' should be emitted in TUs where they
are ODR-used. We need to make sure that statics imported from modules
are correctly added to the 'pending_statics' map so that they get
emitted if nee
On Tue, 2 Jan 2024, 17:49 Patrick Palka, wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and release
> branches (r14-205 was backported everywhere)?
>
Yes, thanks.
> -- >8 --
>
> The adjustment to max_size_type.cc in r14-205-g83470a5cd4c3d2
> inadvertently increased the ex
On Tue, 2 Jan 2024, Jeff Law wrote:
>
> On 1/1/24 20:22, Hans-Peter Nilsson wrote:
> > Tested mmix-knuth-mmixware (where all torture-variants of
> > gcc.dg/torture/inline-mem-cpy-1.c now pass) and native
> > x86_64-pc-linux-gnu. Also stepped through the test for native,
> > w/wo. RUN_FRACTION def
From: trdthg
This patch supports Zacas extension.
It includes instruction's machine description and built-in functions.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_implied_info): Add zacas extensions.
(riscv_ext_version_table): Likewise.
* config/
Am 02.01.24 um 20:37 schrieb Steve Kargl:
On Tue, Jan 02, 2024 at 08:31:15PM +0100, Harald Anlauf wrote:
we might want to update changes.html to reflect this. How about:
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 403feb06..9b16f5e3 100644
--- a/htdocs/gcc-14/ch
On Tue, Jan 2, 2024 at 2:35 AM juzhe.zh...@rivai.ai
wrote:
>
> LGTM assume you have passed the regression.
Committed.
I've rebased this patch, validated that there are no regressions with the patch,
and reworded the commit message a bit before that.
>
>
>
> juzhe
Hello!
I have sent an explanation on ICE in try_combine on pr112494.c [1],and
an argument that explains why we can safely ignore non-COMPARISON_P
mode changes [2].
Can we proceed with the proposed solution?
[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638726.html
[2] https://gcc.g
gccint recommends using ASM_OUTPUT_FUNCTION_LABEL in
ASM_DECLARE_FUNCTION_NAME, but many implementations use
ASM_OUTPUT_LABEL instead. It's inconsistent and prevents changes to
ASM_OUTPUT_FUNCTION_LABEL from affecting the respective targets.
---
gcc/config/aarch64/aarch64.cc | 2 +-
gcc/co
GCC can emit code between the function label and the .LASANPC label,
making the latter unaligned. Some architectures cannot load unaligned
labels directly and require literal pool entries, which is inefficient.
Move the invocation of asan_function_start to
ASM_OUTPUT_FUNCTION_LABEL, which guarant
v1:
https://inbox.sourceware.org/gcc-patches/20231207121005.3425208-1-...@linux.ibm.com/
v1 -> v2: Fix style issues (Jakub).
Jakub has reviewed patch 2 and mentioned that he'd defer the
patch 1 review to Jeff.
Hi,
this is another attempt to fix the .LASANPC alignment on s39
On Tue, Jan 02, 2024 at 08:31:15PM +0100, Harald Anlauf wrote:
>
> we might want to update changes.html to reflect this. How about:
>
> diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> index 403feb06..9b16f5e3 100644
> --- a/htdocs/gcc-14/changes.html
> +++ b/htdocs/gcc-14/
Dear all,
we might want to update changes.html to reflect this. How about:
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 403feb06..9b16f5e3 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -284,6 +284,11 @@ a work-in-progress.
Fortran
Hi All,
I was generating the vector reverse mask without checking if the target
actually supported such an operation.
It also seems like more targets implement VEC_EXTRACT than permute on mask
registers.
So this adds a check for IFN_VEC_EXTRACT support when required and changes
the select first
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and release
branches (r14-205 was backported everywhere)?
-- >8 --
The adjustment to max_size_type.cc in r14-205-g83470a5cd4c3d2
inadvertently increased the execution time of the test by over 5x due to
enabling the two main loops to actua
On 1/1/24 20:22, Hans-Peter Nilsson wrote:
Tested mmix-knuth-mmixware (where all torture-variants of
gcc.dg/torture/inline-mem-cpy-1.c now pass) and native
x86_64-pc-linux-gnu. Also stepped through the test for native,
w/wo. RUN_FRACTION defined to see that it worked as intended.
You may won
On Tue, Dec 12, 2023 at 12:22 AM Andrew Pinski wrote:
>
> Ccmp is not used if the result of the and/ior is used by both
> a GIMPLE_COND and a GIMPLE_ASSIGN. This improves the code generation
> here by using ccmp in this case.
> Two changes is required, first we need to allow the outer statement's
On 12/22/23 12:45, Vineet Gupta wrote:
RVV requires VSET?VL? instructions to dynamically configure VLEN at
runtime. There's a custom pass to do that which has a simple mode
which generates a VSETVL for each V insn and a lazy/optimal mode which
uses LCM dataflow to move VSETVL around, identify/
On 1/1/24 09:48, YunQiang Su wrote:
When building multilib libraries, CC/CXX etc are set with an option
-B*/lib/, instead of -B/lib/.
This will make some trouble in some case, for example building
cross toolchain based on Debian's cross packages:
If we have libc6-dev-i386-amd64-cross packa
On 12/28/23 12:35, Roger Sayle wrote:
Hi Jeff,
Thanks for the speedy review.
On 12/28/23 07:59, Roger Sayle wrote:
This patch fixes PR rtl-optmization/104914 by tweaking/improving the
way that fields are written into a pseudo register that needs to be
kept sign extended.
Well, I think "fi
On 12/30/23 21:34, YunQiang Su wrote:
Right. But that's the whole point behind avoiding the narrowing subreg
and forcing use of a truncate operation.
So basically the question becomes is there a way to modify those bits in
a way that GCC doesn't know that it needs to to truncate/extend?
I
On 1/1/24 19:25, Feng Wang wrote:
gcc/ChangeLog:
* config/riscv/vector-crypto.md: Modify copyright year.
---
gcc/config/riscv/vector-crypto.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/riscv/vector-crypto.md
b/gcc/config/riscv/vector-crypto.md
i
On 1/2/24 06:56, Andreas Schwab wrote:
All new (tsan) tests are working as expected.
* configure.tgt (riscv64-*-linux*): Enable LSan and TSan.
OK
Jeff
Hi Thomas, Andrew,
this patch implements reductions for arrays and structs for OpenACC. Following
the pattern for OpenACC reductions, this is mostly in the respective NVPTX/GCN
backends' *_goacc_reduction_setup/init/fini/teardown hooks, particularly in the
fini part, and [nvptx/gcn]_reduction_up
All new (tsan) tests are working as expected.
* configure.tgt (riscv64-*-linux*): Enable LSan and TSan.
---
libsanitizer/configure.tgt | 5 +
1 file changed, 5 insertions(+)
diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
index d24566a2343..38fc7001ff7 100644
---
From: Pan Li
According to the sematics of no-signed-zeros option, the backend
like RISC-V should treat the minus zero -0.0f as plus zero 0.0f.
Consider below example with option -fno-signed-zeros.
void
test (float *a)
{
*a = -0.0;
}
We will generate code as below, which doesn't treat the min
This patch is to handle the differences in instruction generation
between Vector and XTheadVector. In this version, we only support
partial xtheadvector instructions that leverage directly from current
RVV1.0 with simple adding "th." prefix. For different name xtheadvector
instructions but share sa
Hi Lipeng,
It looks like your draft patch to fix the builds for arm-none-eabi target is
not merged yet, because our arm-none-eabi builds are still broken. Are you
waiting for additional information, or would you be able to fix this issue?
Kind regards,
Vasee
Fro
Ping!
Thanks,
Andrew
Andrew Burgess writes:
> GDB makes use of the libiberty function buildargv for splitting the
> inferior (program being debugged) argument string in the case where
> the inferior is not being started under a shell.
>
> I have recently been working to improve this area of G
> -Original Message-
> From: Jan Hubicka
> Sent: Friday, December 29, 2023 10:32 PM
> To: Tamar Christina
> Cc: rguent...@suse.de; GCC Patches ; nd
>
> Subject: Re: skip vector profiles multiple exits
>
> > Hi Honza,
> Hi,
> >
> > I wasn't sure what to do here so I figured I'd ask.
> >
+ if (TARGET_XTHEADVECTOR)
+ {
+ emit_insn (gen_pred_th_whole_mov (mode, dest, src,
+ RVV_VLMAX, GEN_INT(VLMAX)));
+ return true;
+ }
Move it outside legitimize_move
It should be it:
if (TARGET_THEADVECTOR)
emit_th_move...
DONE;
else if (riscv_vector::legitimize_move (operands[0], &
Segher Boessenkool writes:
> Hi!
>
> On Tue, Oct 24, 2023 at 07:49:10PM +0100, Richard Sandiford wrote:
>> This patch adds a combine pass that runs late in the pipeline.
>
> But it is not. It is a completely new thing, and much closer to
> fwprop than to combine, too.
Well, it is a combine pass.
Move all tests into gcc.target/riscv/rvv/base
All of these:
#include
change them into:
#include "riscv_vector.h"
juzhe.zh...@rivai.ai
From: Feng Wang
Date: 2024-01-02 15:47
To: gcc-patches
CC: kito.cheng; jeffreyalaw; juzhe.zhong; Feng Wang
Subject: [PATCH v5 2/2] RISC-V: Add crypto vector
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN
variants of the vld1 intrinsic for the arm port. This patch adds the
_x4 variants of the vld1 intrinsic.
The previous vld1_x4 has been updated to vld1q_x4 to take into
account that it works with 4-word-length types
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN
variants of the vld1 intrinsic for the arm port. This patch adds the
_x3 variants of the vld1 intrinsic.
The previous vld1_x3 has been updated to vld1q_x3 to take into
account that it works with 4-word-length types
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN
variants of the vst1q intrinsic for the arm port. This patch adds the
_x3 variants of the vst1q intrinsic.
ACLE documents:
https://developer.arm.com/documentation/ihi0053/latest/
ISA documents:
https://developer.a
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN
variants of the vst1 intrinsic for the arm port. This patch adds the
_x4 variants of the vst1 intrinsic.
ACLE documents:
https://developer.arm.com/documentation/ihi0053/latest/
ISA documents:
https://developer.arm
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN
variants of the vst1q intrinsic for the arm port. This patch adds the
_x4 variants of the vst1q intrinsic.
ACLE:
https://developer.arm.com/documentation/ihi0053/latest/
ISA documents:
https://developer.arm.com/doc
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN
variants of the vst1q intrinsic for the arm port. This patch adds the
_x2 variants of the vst1q intrinsic.
ACLE documents:
https://developer.arm.com/documentation/ihi0053/latest/
ISA documents:
https://developer.a
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN
variants of the vld1q intrinsic for the arm port. This patch adds the
_x3 variants of the vld1q intrinsic.
ACLE documents:
https://developer.arm.com/documentation/ihi0053/latest/
ISA documents:
https://developer.a
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN
variants of the vst1 intrinsic for the arm port. This patch adds the
_x2 variants of the vst1 intrinsic.
ACLE documents:
https://developer.arm.com/documentation/ihi0053/latest/
ISA documents:
https://developer.arm
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN
variants of the vld1 intrinsic for the arm port. This patch adds the
_x2 variants of the vld1 intrinsic.
The previous vld1_x2 has been updated to vld1q_x2 to take into
account that it works with 4-word-length types
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN
variants of the vst1 intrinsic for the arm port. This patch adds the
_x3 variants of the vst1 intrinsic.
ACLE documents:
https://developer.arm.com/documentation/ihi0053/latest/
ISA documents:
https://developer.arm
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN
variants of the vld1q intrinsic for the arm port. This patch adds the
_x4 variants of the vld1q intrinsic.
ACLE documents:
https://developer.arm.com/documentation/ihi0053/latest/
ISA documents:
https://developer.a
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN
variants of the vld1q intrinsic for the arm port. This patch adds the
_x2 variants of the vld1q intrinsic.
ACLE documents:
https://developer.arm.com/documentation/ihi0053/latest/
ISA documents:
https://developer.a
From: Ezra Sitorus
Add vld1q, vst1, vst1q and vst1 intrinsics to arm port.
Ezra Sitorus (12):
[GCC] arm: vld1q_types_x2 ACLE intrinsics
[GCC] arm: vld1q_types_x3 ACLE intrinsics
[GCC] arm: vld1q_types_x4 ACLE intrinsics
[GCC] arm: vst1_types_x2 ACLE intrinsics
[GCC] arm: vst1_types_x3
LGTM.
juzhe.zh...@rivai.ai
From: Feng Wang
Date: 2024-01-02 17:18
To: gcc-patches
CC: kito.cheng; jeffreyalaw; juzhe.zhong; Feng Wang
Subject: [PATCH v6 1/2] RISC-V: Add crypto vector builtin function.
Patch v6:Remove unused code.
Patch v5:Rebase.
Patch v4:Merge crypto vector function.def into
Patch v6:Remove unused code.
Patch v5:Rebase.
Patch v4:Merge crypto vector function.def into vector.
Patch v3:Define a shape for vaesz and merge vector-crypto-types.def
into riscv-vector-builtins-types.def.
Patch v2:Optimize function_shape class for crypto_vector.
This patch add the intri
2024-01-02 15:55 juzhe.zhong wrote:
>+/* Static information about a set of crypto vector functions. */
>+struct crypto_function_group_info
>+{
>+ struct function_group_info rvv_function_group_info;
>+ /* Whether the function is available. */
>+ unsigned int (*avail) (void);
>+};
>
87 matches
Mail list logo
