https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111232
JuzheZhong changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111295
--- Comment #5 from JuzheZhong ---
I see. A candidate patch to fix this issue:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629456.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111295
--- Comment #3 from JuzheZhong ---
This code can not be compiled:
cc1plus: warning: command-line option '-Wno-implicit-function-declaration' is
valid for C/ObjC but not for C++
bug.C: In function 'int q()':
bug.C:6:9: warning: empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111295
JuzheZhong changed:
What|Removed |Added
CC||juzhe.zhong at rivai dot ai
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111296
JuzheZhong changed:
What|Removed |Added
CC||juzhe.zhong at rivai dot ai
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311
--- Comment #1 from JuzheZhong ---
Except the known issue (LTO issue). All other issues are either bugus FAILS or
very simple bugs. Fixing them just need a few days (maybe 2 ~ 3days).
I will fix them first before sending new feature patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111317
Bug ID: 111317
Summary: RISC-V: Incorrect COST model for RVV conversions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311
--- Comment #2 from JuzheZhong ---
All FAILS in this PR are not a big deal which will be easily addressed (except
LTO).
We should enable vect.exp tests which have full coverage of vector tests.
But we are still have 2 real FAILS (current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311
--- Comment #3 from JuzheZhong ---
Confirm master GCC FAILs:
gcc FAILs: 166
FAIL: gcc.c-torture/execute/pr53645-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects (test for excess errors)
FAIL: gcc.c-torture/execute/pr53645.c -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111372
--- Comment #4 from JuzheZhong ---
I am not familiar with this stuff.
I would like to see whether kito has good suggestions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #40 from JuzheZhong ---
I try this following code to set ELSE_VALUE:
static tree
riscv_preferred_else_value (unsigned ifn, tree vectype, unsigned int nops,
tree *ops)
{
if (riscv_v_ext_mode_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #25 from JuzheZhong ---
(In reply to rsand...@gcc.gnu.org from comment #24)
> Heh, nice hack. :) But I guess this shows that the type checking of
> internal functions isn't as strong it should be.
>
> IMO it's wrong to pass a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #29 from JuzheZhong ---
(In reply to JuzheZhong from comment #27)
> (In reply to rsand...@gcc.gnu.org from comment #26)
> > But this is how technical debt builds up. We'd be making a change
> > that doesn't match the type system,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #28 from JuzheZhong ---
(In reply to JuzheZhong from comment #27)
> (In reply to rsand...@gcc.gnu.org from comment #26)
> > But this is how technical debt builds up. We'd be making a change
> > that doesn't match the type system,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #27 from JuzheZhong ---
(In reply to rsand...@gcc.gnu.org from comment #26)
> But this is how technical debt builds up. We'd be making a change
> that doesn't match the type system, and that we know to be wrong
> in principle. And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337
--- Comment #3 from JuzheZhong ---
(In reply to Richard Biener from comment #2)
> vect_patt_67.34_168 = VEC_COND_EXPR }>;
> vect_patt_68.35_169 = (vector([4,4]) int) vect_patt_67.34_168;
>
> ->
>
> vect_patt_68.35_169 = VEC_COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337
--- Comment #11 from JuzheZhong ---
(In reply to Robin Dapp from comment #10)
> I would be OK with the riscv implementation, then we don't need to touch
> isel. Maybe a future vector extension will also help us here so we could
> just switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337
--- Comment #9 from JuzheZhong ---
So, should we support this pattern in RISC-V backend ?
Or adjust gimple-isel to generate these 4 STMTs naturally?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111375
--- Comment #3 from JuzheZhong ---
(In reply to Jeremy Bennett from comment #2)
> (In reply to JuzheZhong from comment #1)
> > I can't reproduce the ICE in your testcase with same command.
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #23 from JuzheZhong ---
Hi, Richard and Richi.
I found a way to simulate "undefine" in COND_LEN_xxx pattern for the ELSE value
that doesn't matter.
First, return size type 0 in else_value target hook:
/* Use size_type 0 which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337
--- Comment #7 from JuzheZhong ---
(In reply to rguent...@suse.de from comment #6)
> On Tue, 12 Sep 2023, juzhe.zhong at rivai dot ai wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337
> >
> > --- Comment #5 from JuzheZhong ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111375
JuzheZhong changed:
What|Removed |Added
CC||juzhe.zhong at rivai dot ai
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337
--- Comment #5 from JuzheZhong ---
Oh. I see.
(define_expand "@vcond_mask_"
[(match_operand:VB 0 "register_operand")
(match_operand:VB 3 "register_operand")
(match_operand:VB 1 "nonmemory_operand")
(match_operand:VB 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337
JuzheZhong changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #30 from JuzheZhong ---
Hi.Richard.
I understand your conern:
If we are possible have this following possible rule to fold to ELSE value in
the future:
1. (cond_len all-false a b c len bias)
2. (cond_len any mask a b c len bias)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111320
--- Comment #1 from JuzheZhong ---
Not only inorder reduction.
But also un-order reduction:
https://godbolt.org/z/sn5jbWPbd
#include
int
foo (int16_t * __restrict a, int n, int * __restrict cond)
{
int r = 0;
for (int i = 0; i < 8;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111401
Bug ID: 111401
Summary: Middle-end: Missed optimization of
MASK_LEN_FOLD_LEFT_PLUS
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #33 from JuzheZhong ---
Is it reasonable this way ?
ELSE VALUE = make_temp_ssa_name (vectype, NULL, "undefine_");
Then in the later "expand" stage:
defind_expand "cond_len_xxx"
...
if (REG_EXPR (operand) == "undefine") {
gen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #37 from JuzheZhong ---
(In reply to Richard Biener from comment #35)
> (In reply to Richard Biener from comment #34)
> > The ELSE value of type TYPE would be constructed like
> >
> > tree var = create_tmp_var (type);
> > tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #36 from JuzheZhong ---
(In reply to Richard Biener from comment #34)
> The ELSE value of type TYPE would be constructed like
>
> tree var = create_tmp_var (type);
> tree else_val = get_or_create_ssa_default_def (cfun, var);
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #32 from JuzheZhong ---
(In reply to Richard Biener from comment #31)
> On GIMPLE an "undefined" operand representation would be the default
> definition of an SSA name with the appropriate type. That's a somewhat
> "heavy"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53
--- Comment #3 from JuzheZhong ---
(In reply to Robin Dapp from comment #2)
> With the current trunk we don't spill anymore:
>
> (VLS)
> .L4:
> vle32.v v2,0(a5)
> vadd.vv v1,v1,v2
> addia5,a5,16
> bne a5,a4,.L4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111232
Bug ID: 111232
Summary: RISC-V: Failed to combine vwmul + vadd into vwmacc
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311
--- Comment #4 from JuzheZhong ---
Update status:
All C++ FAILs are fixed.
There are only 38 FAILs in total:
FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.vsetvl, -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337
Bug ID: 111337
Summary: ICE in gimple-isel.cc for RISC-V port
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111832
Bug ID: 111832
Summary: RISC-V: ICE on dynamic LMUL
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #13 from JuzheZhong ---
Confirm ARM SVE has the same issue:
https://godbolt.org/z/TjcaM6xsP
#include
void fn(uint8_t * __restrict out) {
uint8_t arr[32] = {1, 2, 7, 1, 3, 4, 5, 3, 1, 0, 1, 2, 4, 4, 9, 9, 1, 2, 7,
1, 3, 4, 5,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111848
Bug ID: 111848
Summary: RISC-V: RVV cost model pick unexpected big LMUL
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111848
--- Comment #1 from JuzheZhong ---
Sorry, it pick LMUL = 4:
f3:
ble a4,zero,.L11
csrrt0,vlenb
sllit1,t0,4
csrra6,vlenb
sub sp,sp,t1
csrra5,vlenb
sllia6,a6,3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092
--- Comment #8 from JuzheZhong ---
(In reply to Maciej W. Rozycki from comment #7)
> Thank you for all your explanations. I think I'm still missing something
> here, so I'll write it differently (and let's ignore the tail-agnostic vs
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092
--- Comment #9 from JuzheZhong ---
(In reply to Maciej W. Rozycki from comment #7)
> Thank you for all your explanations. I think I'm still missing something
> here, so I'll write it differently (and let's ignore the tail-agnostic vs
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111888
JuzheZhong changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092
--- Comment #2 from JuzheZhong ---
To demonstrate the idea, here is a simple example to make you easier understand
the idea:
https://godbolt.org/z/Gxzjv48Ec
#include "riscv_vector.h"
void foo(int32_t *in1, int32_t *in2, int32_t *in3, int32_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092
JuzheZhong changed:
What|Removed |Added
CC||juzhe.zhong at rivai dot ai
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #29 from JuzheZhong ---
insn-output.cc still has over 1.7 Million lines codes.
Is it possible split this file into 10 files too ?
It seems that it is also an issue for compile time ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112326
Bug ID: 112326
Summary: Redundant vsetvl in fixed-vlmax autovectorization
codes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112323
Bug ID: 112323
Summary: aarch64: Missed operator support on ARM SVE intrinsic
type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111794
JuzheZhong changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112327
Bug ID: 112327
Summary: RVV: Redundant vmv1r for widen reduction
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112331
--- Comment #1 from JuzheZhong ---
I suspect it is SRA issue again ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112331
Bug ID: 112331
Summary: middle-end: Fail vectorization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112327
JuzheZhong changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112331
--- Comment #4 from JuzheZhong ---
I see.
It does vectorize it with -fno-vect-cost-model -fno-loop-interchange:
https://gcc.godbolt.org/z/8EEWcPro3
Codegen same as LLVM.
I am gonna revisit it in GCC-15 (GCC-14 stage 1 is closing soon).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112331
--- Comment #2 from JuzheZhong ---
Reduced case:
#include
#define LEN 32000
#define ntimes 20
#define TYPE int
#define lll LEN
#define LEN2 256
#define ALIGNMENT 16
__attribute__ ((aligned(ALIGNMENT))) TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111931
JuzheZhong changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112326
JuzheZhong changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111401
JuzheZhong changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311
--- Comment #12 from JuzheZhong ---
signbit execution issue should be ignored. It's ISA issue not compiler issue.
I knew this issue long time ago and confirm Clang has the sam issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111721
JuzheZhong changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 111721, which changed state.
Bug 111721 Summary: RISC-V: Failed to SLP for gather_load in RVV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111721
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112387
Bug ID: 112387
Summary: RISC-V: failed to SLP INT64 gather load
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112420
--- Comment #2 from JuzheZhong ---
(In reply to Richard Biener from comment #1)
> We end up using gathers for the strided load which would be OK and avoid the
> issue noted in the comment. Thus we get true from
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112420
Bug ID: 112420
Summary: Unexpected vectorization for RISC-V
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112399
JuzheZhong changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112420
JuzheZhong changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106694
--- Comment #11 from JuzheZhong ---
(In reply to Richard Sandiford from comment #10)
> Some of the SME changes I'm working on fix this, but I'm not sure how widely
> we'll be able to use them on non-SME code. Assigning myself just in case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760
JuzheZhong changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112431
Bug ID: 112431
Summary: RISC-V GCC-15 feature: Support register overlap on
widen RVV instructions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112431
--- Comment #2 from JuzheZhong ---
My colleague Lehua takes this response to support this feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112433
Bug ID: 112433
Summary: RISC-V GCC-15 feature: Split register allocation into
RVV and non-RVV, and make vsetvl PASS run between them
Product: gcc
Version: 14.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311
--- Comment #15 from JuzheZhong ---
Update status:
There are only these following dump FAILs:
FAIL: gcc.dg/signbit-2.c scan-tree-dump optimized "\\s+>\\s+{ 0(, 0)+ }"
FAIL: gcc.dg/signbit-2.c scan-tree-dump-not optimized "\\s+>>\\s+31"
XPASS:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112431
JuzheZhong changed:
What|Removed |Added
CC||lehua.ding at rivai dot ai
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112433
--- Comment #2 from JuzheZhong ---
(In reply to Kito Cheng from comment #1)
> Give few more background why LLVM must do that way: LLVM can't allocate new
> pseudo register during register allocation process, however spilling vector
> register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106694
--- Comment #12 from JuzheZhong ---
(In reply to Richard Sandiford from comment #10)
> Some of the SME changes I'm working on fix this, but I'm not sure how widely
> we'll be able to use them on non-SME code. Assigning myself just in case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092
--- Comment #6 from JuzheZhong ---
> I have troubles chasing one down and the source code is so
> convoluted with macros I can't even find the implementation.
I am sorry for causing confusion to you here.
But because of the RVV fusion rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092
--- Comment #5 from JuzheZhong ---
Yes. I am agree that some arch prefer agnostic than undisturbed even with more
vsetvls. That's why I have post PR for asking whether we can have a option like
-mprefer-agosnotic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112387
--- Comment #1 from JuzheZhong ---
Oh. I see.
with -fno-vect-cost-model, it can SLP now:
https://godbolt.org/z/q5se4sd9x
foo:
beq a3,zero,.L8
csrra6,vlenb
srlia4,a6,3
sllia3,a3,1
neg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112399
Bug ID: 112399
Summary: RISC-V: Missed AVL propagation for complicate
reduction case
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112401
Bug ID: 112401
Summary: RISC-V: So many redundant move instructions due to
subreg handling on vector mode
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112401
--- Comment #1 from JuzheZhong ---
GCC ASM:
subreg_to_reg_1:
li a5,32
vsetvli zero,a5,e32,m8,ta,ma
vle32.v v16,0(a0)
vmv1r.v v8,v16
vmv1r.v v7,v17
vmv1r.v v6,v18
vmv1r.v v5,v19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #29 from JuzheZhong ---
(In reply to Richard Biener from comment #28)
> I tried to look up the requirements of __riscv_vle8_v_u8m2 in the vector
> intrinsic specs but besides listing all those intrinsics the spec doesn't
> contain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #32 from JuzheZhong ---
26% time reduction seems not enough.
Maybe we still need to optimize MD patterns to fix this issue ?
But I have no idea to optimize it since I already tried my best to reduce
them.
According to RVV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111791
--- Comment #7 from JuzheZhong ---
I don't think this is popcount vectorization issue.
This code should not be vectorized. It's true this code won' be vectorized if
we
use default COST model.
So this is not an issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #15 from JuzheZhong ---
After investigation:
I found it seems to be an issue to variable-length vector:
https://godbolt.org/z/6Wrjz9ofE
void fn (char * restrict out, int x)
{
[local count: 1073741824]:
MEM[(int8x16_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111450
Bug ID: 111450
Summary: RISC-V: Missed optimized for strided load/store with
stride = element width
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111451
Bug ID: 111451
Summary: RISC-V: Missed optimization of vrgather.vv into
vrgatherei16.vv
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111545
JuzheZhong changed:
What|Removed |Added
CC||juzhe.zhong at rivai dot ai
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111451
JuzheZhong changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #44 from JuzheZhong ---
Fixed on the trunk.
Hi, LiXu. Could you verify it with trunk GCC and close this PR?
Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111451
JuzheZhong changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111450
JuzheZhong changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111492
Bug ID: 111492
Summary: RISC-V: Dynamic LMUL picking incorrect LMUL
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111451
JuzheZhong changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111506
JuzheZhong changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111624
JuzheZhong changed:
What|Removed |Added
CC||juzhe.zhong at rivai dot ai
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111545
--- Comment #4 from JuzheZhong ---
Confirm this is the latent bug in VSETVL PASS which is already existed for a
long time.
Lehua is working on refactoring Phase 1 and Phase 2 of VSETVL PASS which will
fix all potential issues of VSETVL PASS.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109088
--- Comment #7 from JuzheZhong ---
Update the analysis:
We failed to recognize it as reduction because, the PHI result has 2 uses:
# result_20 = PHI
...
_11 = result_20 + 10; > first use
result_17 = _4 + _11;
_23 = _4 > _7;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109088
--- Comment #12 from JuzheZhong ---
(In reply to Richard Biener from comment #11)
> I don't think strip_nop_cond_scalar_reduction is the place to adjust here,
> maybe it's the caller. I don't have time to dig into the specific issue
> right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109088
--- Comment #10 from JuzheZhong ---
(In reply to Richard Biener from comment #9)
> (In reply to JuzheZhong from comment #8)
> > It's because the order of the operations we are doing:
> >
> > For code as follows:
> >
> > result += mask ? a[i]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111590
JuzheZhong changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
1 - 100 of 555 matches
Mail list logo
