+/* 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);
+};
What is this used for ?
juzhe.zh...@rivai.ai
From:
Patch v5: Rebase.
Patch v4: Add some RV32 vx constraint testcase.
Patch v3: Refine crypto vector api-testing case s.
Patch v2: Update march info according to the change of riscv-common.c
This patch add crypto vector api-testing cases based on
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 intrinsic funtions of crypto
In
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d1eacedc6d9ba9f5522f2c8d49ccfdf7939ad72d
I optimize COND_LEN_xxx pattern with dummy len and dummy mask with too simply
solution which
causes redundant vsetvli in the following case:
vsetvli a5,a2,e8,m1,ta,ma
vle32.v v8,0(a0)
On Fri, Dec 22, 2023 at 6:25 PM Roger Sayle wrote:
>
>
> This patch resolves the second part of PR target/112992, building upon
> Hongtao Liu's solution to the first part.
>
> The issue addressed by this patch is that when initializing vectors by
> broadcasting integer constants, the compiler has
But the riscv_print_operand() function returns void.
We cannot return instructions like riscv_output_move.
I think the briefest approach is to add some logic in
the vsetvl patterns.
"TARGET_VECTOR"
{ return TARGET_XTHEADVECTOR ? "vsetvli\t%0,%1,e%2,%m3" :
This patch fixes the following situation:
vl4re16.v v12,0(a5)
...
vl4re16.v v16,0(a3)
vs4r.v v12,0(a5)
...
vl4re16.v v4,0(a0)
vs4r.v v16,0(a3)
...
vsetvli a3,zero,e16,m4,ta,ma
...
vmv.v.x v8,t6
vmsgeu.vv v2,v16,v8
vsub.vv v16,v16,v8
vs4r.v v16,0(a5)
...
vs4r.v v4,0(a0)
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 wonder what about the "sibling" tests
For vsetvl issues, what we want to do here is to directly
remove "t" and "m".
If we add TARGET_XTHEADVECTOR logic in case "p" in
riscv_print_operand, how can we remove "t" and "m"? If I
use "break", assembly like "th.vsetvli zero,a5,e8,m1,t,m"
will be returned.
if (TARGET_THEADVECTOR)
...
else
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
index e40b1543954..9625014e45e 100755
---
Committed.
gcc/ChangeLog:
* config/riscv/riscv-vector-costs.cc: Move STMT_VINFO_TYPE (...) to
local.
---
gcc/config/riscv/riscv-vector-costs.cc | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/gcc/config/riscv/riscv-vector-costs.cc
Pushed to r14-6879 and modified this issue.
在 2023/12/19 下午8:37, Xi Ruoyao 写道:
On Tue, 2023-12-19 at 19:04 +0800, Lulu Cheng wrote:
+(define_insn "@add_tls_le_relax"
+ [(set (match_operand:P 0 "register_operand" "=r")
+ (unspec:P [(match_operand:P 1 "register_operand" "r")
+
LGTM assume you have passed the regression.
juzhe.zh...@rivai.ai
From: Jun Sha (Joshua)
Date: 2023-12-29 12:10
To: gcc-patches
CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; jeffreyalaw;
christoph.muellner; juzhe.zhong; Jun Sha (Joshua); Jin Ma; Xianmiao Qu
Subject: [PATCH v4] RISC-V:
LGTM assume you have passed the regression.
juzhe.zh...@rivai.ai
From: Jun Sha (Joshua)
Date: 2023-12-29 12:06
To: gcc-patches
CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; jeffreyalaw;
christoph.muellner; juzhe.zhong; Jun Sha (Joshua); Jin Ma; Xianmiao Qu
Subject: [PATCH v4] RISC-V:
Co-Authored by: Songhe Zhu
Co-Authored by: Ciyan Pan
gcc/ChangeLog:
* config/riscv/iterators.md: Add rotate insn name.
* config/riscv/riscv.md: Add new insns name for crypto vector.
* config/riscv/vector-iterators.md: Add new iterators for crypto vector.
*
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.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2024-01-01 01:43
To: Jun
Hi Thomas!
Am 30.12.23 um 12:08 schrieb Thomas Koenig:
Replying to myself...
I think this also desevers a mention in changes.html. Here is something
that I came up with. OK? Or does anybody have suggestions for a better
wording?
Or maybe this is better:
diff --git
I know we're deep into stage3 and about to transition to stage4. So if
the consensus is for this to wait, I'll understand
This it the V3 of the ext-dce patch based on Joern's work from last year.
Changes since V2:
Handle MINUS
Minor logic cleanup for SUBREGs in ext_dce_process_sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113191
I've posted the report here, I ended up doing a bit more investigation,
so the contents might interest you. I'm really starting to think that
we want to do a more thorough re-engineering of how using declarations
are handled, instead of handling
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 packages installed on
a non-x86 machine.
That was faster than I expected, the problem is exactly just that we
aren't implementing [over.match.funcs.general.4] at all. The result of
compparms for the 2 functions is false which I believe to be wrong. I
believe we have a few choices here, but no matter what we go with it
will be a bit of an
I've been at this for a while, and I'm not sure what the proper way to
fix this is.
```
struct S;
struct B {
void f(this S&) {}
void g() {}
};
struct S : B {
using B::f;
using B::g;
void f() {}
void g(this S&) {}
};
int main()
{
S s{};
s.f();
s.g();
}
```
In short, the call
Thanks Jeff for the confirmation and suggestions. It looks like not a corner
case for the option no-signed-zero.
Consider 2 sample function as below with build with option " -march=rv64gcv
-mabi=lp64d -O2 -fno-signed-zeros".
void
__attribute__ ((noinline))
test_float_zero_assign_0 (float *a)
{
23 matches
Mail list logo
