https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119832
--- Comment #1 from Kito Cheng ---
Created attachment 61135
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61135&action=edit
0001-RISC-V-Implement-TARGET_MODE_CONFLUENCE.patch
My working patch for this bug
-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kito at gcc dot gnu.org
Target Milestone: ---
Target: riscv
How to reproduce:
```shell
$ riscv64-unknown-linux-gnu-gcc test.cc -S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116125
--- Comment #10 from Kito Cheng ---
ping, does it possible to back port to release branches? it seems land on trunk
for a while :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119477
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118827
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117955
--- Comment #4 from Kito Cheng ---
I can't reproduce that by the top of trunk with your option, could you check
does the bug still can be reproduced by trunk?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118182
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118384
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118182
--- Comment #2 from Kito Cheng ---
（on the train yet but I can describe few details for my current solution
1. Always use vl=1 for vfmv.s.f
- this will introduce one extra vsetvli, but at least it correct, and LLVM use
same code gen as well
2
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kito at gcc dot gnu.org
Target Milestone: ---
Created attachment 59955
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59955&action=edit
Reduced testcase f
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kito at gcc dot gnu.org
CC: jeffreyalaw at gmail dot com, juzhe.zhong at rivai dot ai,
palmer at gcc dot gnu.org, pan2.li at intel dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116595
--- Comment #5 from Kito Cheng ---
GCC 14 with enable checking will trigger that as well, thanks for remind that
detail, I forgot trunk will enable checking by default but release branch isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116595
--- Comment #2 from Kito Cheng ---
Hmmm, it's not well defined in the rvv intrinsic doc, but I suppose this should
at least work (compile-able) without crash, also it seems works fine on GCC 14
,
||kito at gcc dot gnu.org
--- Comment #2 from Kito Cheng ---
Hi Christoph:
Not sure if Vrull is still care theadvector?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116278
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116111
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115995
--- Comment #3 from Kito Cheng ---
We have an internal qemu patch for adding an option to trigger this damm
behavior by default, and plan to upstream soon...let me ask our Qemu folk if I
can get the patch out first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115795
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725
--- Comment #13 from Kito Cheng ---
FYI: PR for riscv-gnu-toolchain:
https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1501
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725
--- Comment #12 from Kito Cheng ---
Qemu has provide two option to fill up all-one to agnostic policy:
rvv_ta_all_1s and rvv_ma_all_1s*, I guess we could enable that by default in
riscv-gnu-toolchain to discover more potential bugs.
* qemu-r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725
--- Comment #2 from Kito Cheng ---
TU may not help for this case since we can't guarantee it's use v1 outside, I
mean the argument is passed via a1 (pointer) rather than passed via v1.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kito at gcc dot gnu.org
Target Milestone: ---
Target: riscv64-unknown-linux-gnu
# What's up?
A loop induction variable initialized from __builtin_ctz (x), an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114988
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114747
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113095
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111234
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
||kito at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2024-04-29
--- Comment #1 from Kito Cheng ---
I can reproduce on my side
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114172
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
|--- |FIXED
CC||kito at gcc dot gnu.org
--- Comment #5 from Kito Cheng ---
Checked this has fixed on trunk and GCC 13 branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111234
--- Comment #4 from Kito Cheng ---
Fixed on trunk, but still ICE on 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114130
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
--- Comment #4 from Kito Cheng ---
Reduced case:
```c
typedef long c;
#pragma riscv intrinsic "vector"
template struct d {};
struct e {
using f = d<0>;
};
struct g {
using f = e::f;
};
template using h = g::f;
template long k(d);
vbool16_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106530
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109349
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113742
--- Comment #1 from Kito Cheng ---
Thanks, forward and assigned this to our (SiFive) engineer :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #23 from Kito Cheng ---
> I am considering whether we should disable LICM for RISC-V by default if
> vector is enabled ?
That's will cause regression for other program, also may hurt those program not
vectorized but benefited from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113240
--- Comment #6 from Kito Cheng ---
> There needs to be a -Wabi warning for this too for the change between
> versions.
This bug only happened on trunk, and GCC 13 is OK, so I think it's not the
case?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112478
Kito Cheng changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112109
--- Comment #1 from Kito Cheng ---
Just note:
I would like to introduce `-mstringop-strategy=`, `-mmemcpy-strategy=` and
-mmemset-strategy=` option to control the behavior like x86.
the possible option list from my mind is:
- auto: current st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537
--- Comment #11 from Kito Cheng ---
It's not scope of auto vectorization, so I would suggest add something like
`-mstringop-strategy=*` or `-mmemcpy-strategy=*` (from x86) or
`-param=riscv-mops-memcpy-size-threshold=` (from aarch64).
Personally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537
--- Comment #8 from Kito Cheng ---
That remind me we may need one option like something -mgeneral-regs-only in
aarch64 and also for target attribute.
BTW, clang has an generic option called -mno-implicit-float can did similar
thing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112478
--- Comment #8 from Kito Cheng ---
Proposed fix:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636466.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112527
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #1
||kito at gcc dot gnu.org
Last reconfirmed||2023-11-14
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |kito at gcc dot gnu.org
--- Comment #6 from Kito Cheng ---
Oh, I guess I know what happened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112433
--- Comment #4 from Kito Cheng ---
Yeah, 3 major goal in LLVM is improving scheduling, partial spilling and
re-materialization, but none of those points are issue for RISC-V GCC :P
Ref:
https://docs.google.com/presentation/d/1BOYNYKe1T-u3Q5HXRr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #12 from Kito Cheng ---
oh, yeah, you are right, it already take a5 to splat, so it's right, and as you
said it must be VLMAX, unless it AVL prorogation for both splat and the
following vadd.vv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #10 from Kito Cheng ---
(In reply to JuzheZhong from comment #9)
> I have a draft patch to fix it:
>
> foo:
> ble a0,zero,.L5
> vsetvli a5,zero,e32,m1,ta,ma
> vid.v v2
> .L3:
> vsetvli a5,a0,e32,m1,ta,m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #8 from Kito Cheng ---
> Oh. I understand it now. I think it's a bug.
>
> And.. I just take a look at my internal LLVM...
> Also has same issue
>
> I think we need to adapt the Gimple IR here:
>
> _35 = .SELECT_VL (ivtmp_33,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #6 from Kito Cheng ---
The key is the splat of VLMAX instruction need move into loop body, but AVL
propagation should still able to do:
```
foo(int, int*, int*):
ble a0,zero,.L5
csrra5,vlenb
srlia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #5 from Kito Cheng ---
Assume:
VLEN = 128 and n = 5, *in is {0, 0, 0, 0, 0}
so VLMAX = 4 for e32m1
It can be run with vl = 4 for first iteration, and vl = 1 vl for second
iteration
But it could be something like that: vl = 3 for f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #2 from Kito Cheng ---
oh, but the root cause might be little bit deeper, not just the problem of
propagation or not propagation the AVL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112431
--- Comment #3 from Kito Cheng ---
Share some thought from my end: we've tried at least 3 different approach on
LLVM side before, and now we model that as "partial early clobber", we plan to
upstream this on LLVM side but just didn't get high e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112433
--- Comment #1 from Kito Cheng ---
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 with specific length may require scratch register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111926
--- Comment #2 from Kito Cheng ---
Forgot to mention, personally I love idea to simplify code gen, I could imagine
that's definitely an optimization for specific uarch :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111926
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #1
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kito at gcc dot gnu.org
Target Milestone: ---
Symptom:
A typical popcount implementation with Brian Kernighan’s algorithm, vectorizer
has recognized that as popcount, but...come with strange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #14 from Kito Cheng ---
Some info for generated files:
-
File blankcomment code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111664
Kito Cheng changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #13
|RESOLVED
CC||kito at gcc dot gnu.org
--- Comment #2 from Kito Cheng ---
fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111372
--- Comment #5 from Kito Cheng ---
> Ok, but it's better to have configure option or something else just
> for toolchains that definitely do not use vector extension
I can understand that there would be such a demand in the embedded world, but
||kito at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #3 from Kito Cheng ---
Fixed on trunk
||kito at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #2 from Kito Cheng ---
Fixed on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111037
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
|RESOLVED
CC||kito at gcc dot gnu.org
--- Comment #2 from Kito Cheng ---
Fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110560
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109773
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109725
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111065
--- Comment #4 from Kito Cheng ---
I guess I skip too much detail here, the multilib for linux isn’t really honor
to the reause rule in the multilib config file for a while.
That just control how multilib build, e.g. build ilp32 with which arch
||kito at gcc dot gnu.org
--- Comment #1 from Kito Cheng ---
One major issue around multilib for linux is we only encode abi to the path, so
it hard to extend that like baremetal toolchain.
Assignee: unassigned at gcc dot gnu.org
Reporter: kito at gcc dot gnu.org
CC: juzhe.zhong at rivai dot ai
Target Milestone: ---
Target: riscv64
Reduced case:
```
#include
void foo(_Float16 y, int64_t *i64p)
{
vint64m1_t vx =__riscv_vle64_v_i64m1 (i64p, 1
||kito at gcc dot gnu.org
--- Comment #1 from Kito Cheng ---
Ooops, I thought those target hook should implement when we have implement
target attribute, anyway thanks for the hint!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #4 from Kito Cheng ---
> OK, so TA is either merge or all-ones.
Yes, your understand is correct, just few more detail is that can be mixing
with either merge or all-ones.
e.g.
An 4 x i32 vector with mask 1 0 1 0
Op = | a | b |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #2 from Kito Cheng ---
And seems we already has such constraint for a while, not sure why GCC 13 did
that, I saw the status has changed to ASSIGNED, so I assume Vineet you are
already spending time on that, so I will just stop there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110696
Kito Cheng changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110478
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110448
Kito Cheng changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110448
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110264
Kito Cheng changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110188
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109972
--- Comment #3 from Kito Cheng ---
We care but it's lower priority compare to other configuration, so create bug
to tracking here should be best solution for now :P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109974
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109547
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109743
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109748
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109748
--- Comment #1 from Kito Cheng ---
Is this also happened in GCC 13 branch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109617
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109272
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109547
Kito Cheng changed:
What|Removed |Added
Summary|RISC-V: Multiple vsetvli|[13] RISC-V: Multiple
|f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535
Kito Cheng changed:
What|Removed |Added
Target Milestone|--- |13.2
Summary|internal compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109547
Kito Cheng changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535
Kito Cheng changed:
What|Removed |Added
Last reconfirmed||2023-04-17
Status|UNCONFIRMED
1 - 100 of 218 matches
Mail list logo
