https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105733
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106149
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101275
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101275
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=106530
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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=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=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 |
||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!
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 ---
One major issue around multilib for linux is we only encode abi to the path, so
it hard to extend that like baremetal toolchain.
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
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=109773
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110560
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
|RESOLVED
CC||kito at gcc dot gnu.org
--- Comment #2 from Kito Cheng ---
Fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111037
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
||kito at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #2 from Kito Cheng ---
Fixed on trunk
||kito at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #3 from Kito Cheng ---
Fixed on trunk
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
|RESOLVED
CC||kito at gcc dot gnu.org
--- Comment #2 from Kito Cheng ---
fixed
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
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
--- Comment #14 from Kito Cheng ---
Some info for generated files:
-
File blankcomment code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116278
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
,
||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=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
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=109228
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109244
--- Comment #4 from Kito Cheng ---
Gonna commit the fix soon, and following code is the reduced case which is
reduced from your attachment.
Reduced case (reduced by creduce)
typedef int a;
using c = float;
template < typename > using e = int;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109244
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109228
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109312
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109328
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
||kito at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |pan2.li at intel dot com
--- Comment #4 from Kito Cheng ---
Pan Li from Intel is working on fixing that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109349
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109328
Kito Cheng changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109461
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109479
Kito Cheng changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109479
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535
--- Comment #5 from Kito Cheng ---
Confirmed the the output is text file, it's just suffixed with .out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109104
Kito Cheng changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535
Kito Cheng changed:
What|Removed |Added
Last reconfirmed||2023-04-17
Status|UNCONFIRMED
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
Target Milestone|--- |13.2
Summary|internal compiler
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=109272
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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=109535
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=109748
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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=114639
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
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=114130
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=111234
--- Comment #4 from Kito Cheng ---
Fixed on trunk, but still ICE on 13
|--- |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=114172
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=111234
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=114747
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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
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=111926
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #1
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=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=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=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=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=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
--- 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 #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 #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 #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 #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=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
||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=112527
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #1
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=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=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=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=112478
Kito Cheng changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=109547
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=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=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=110264
Kito Cheng changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=110448
Kito Cheng changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
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=110696
Kito Cheng changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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=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=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
101 - 200 of 218 matches
Mail list logo
