https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #30 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:990769a343f090088f5025ad233f88824b2c6263
commit r14-5769-g990769a343f090088f5025ad233f88824b2c6263
Author: Pan Li
Date: Mon Nov 13 11:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #31 from Li Pan ---
We still have some unnecessary code here, which is stack-related, will take
care of it in another PATCH.
After this patch:
test:
lui a5,%hi(.LANCHOR0)
addia5,a5,%lo(.LANCHOR0)
li
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 _a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #28 from Richard Biener ---
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 _any_ documentation? The 2nd arg is named 'vl' wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #27 from Li Pan ---
Hi Richard and Juzhe.
I investigated this issue recently and noticed that it may be related to the
array size of the constant memory. Assume we have 2 functions as below.
vuint8m1_t fn_0 () {
uint8_t arr[3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #26 from rguenther at suse dot de ---
On Thu, 19 Oct 2023, juzhe.zhong at rivai dot ai wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
>
> --- Comment #25 from JuzheZhong ---
> (In reply to rguent...@suse.de from comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #25 from JuzheZhong ---
(In reply to rguent...@suse.de from comment #24)
> On Thu, 19 Oct 2023, juzhe.zhong at rivai dot ai wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
> >
> > --- Comment #23 from JuzheZhong -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #24 from rguenther at suse dot de ---
On Thu, 19 Oct 2023, juzhe.zhong at rivai dot ai wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
>
> --- Comment #23 from JuzheZhong ---
> (In reply to rguent...@suse.de from comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #23 from JuzheZhong ---
(In reply to rguent...@suse.de from comment #22)
> On Thu, 19 Oct 2023, juzhe.zhong at rivai dot ai wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
> >
> > --- Comment #21 from JuzheZhong -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #22 from rguenther at suse dot de ---
On Thu, 19 Oct 2023, juzhe.zhong at rivai dot ai wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
>
> --- Comment #21 from JuzheZhong ---
> (In reply to rguent...@suse.de from comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #21 from JuzheZhong ---
(In reply to rguent...@suse.de from comment #20)
> On Thu, 19 Oct 2023, juzhe.zhong at rivai dot ai wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
> >
> > --- Comment #19 from JuzheZhong -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #20 from rguenther at suse dot de ---
On Thu, 19 Oct 2023, juzhe.zhong at rivai dot ai wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
>
> --- Comment #19 from JuzheZhong ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #19 from JuzheZhong ---
(In reply to Richard Biener from comment #18)
> With RVV you have intrinsic calls in GIMPLE so nothing to optimize:
>
> vbool8_t fn ()
> {
> vbool8_t vmask;
> vuint8m1_t vand_m;
> vuint8m1_t varr;
> u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #18 from Richard Biener ---
With RVV you have intrinsic calls in GIMPLE so nothing to optimize:
vbool8_t fn ()
{
vbool8_t vmask;
vuint8m1_t vand_m;
vuint8m1_t varr;
uint8_t arr[32];
[local count: 1073741824]:
arr =
"\x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #17 from JuzheZhong ---
(In reply to Richard Biener from comment #16)
> The issue is that we cannot CSE a VLA typed "load" (whatever that is) to a
> constnant.
>
> char arr[] = {1, 2, 7, 1, 3, 4, 5, 3, 1
> , 0, 1, 2, 4, 4, 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #16 from Richard Biener ---
The issue is that we cannot CSE a VLA typed "load" (whatever that is) to a
constnant.
char arr[] = {1, 2, 7, 1, 3, 4, 5, 3, 1
, 0, 1, 2, 4, 4, 9, 9, 1, 2, 7, 1, 3, 4, 5, 3,
1, 0, 1, 2, 4, 4,
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 *)out_2(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #14 from Li Pan ---
Looks like option -fmerge-all-constants doesn't work for this case, as well as
RISC-V.
For RISC-V, the CLOBBER exists after tree gimple.
void test (vuint8m1_t *out) {
uint8_t arr[32] = {1, 2, 7, 1, 3, 4, 5, 3
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, 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #12 from JuzheZhong ---
Hi, Andrew.
I have another try:
https://godbolt.org/z/heKxcMWsY
change the load into normal load of arr:
vuint8m1_t varr = *(vuint8m1_t*)arr;
Like you said,
The issue is gone (as good as LLVM):
fn:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #11 from JuzheZhong ---
(In reply to Andrew Pinski from comment #10)
> The issues is GCC does prop the load/store for arr into __riscv_vle8_v_u8m1
> really.
Ok. Do you know why GCC prop load/store for arr into __riscv_vle8_v_u8m1?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #10 from Andrew Pinski ---
The issues is GCC does prop the load/store for arr into __riscv_vle8_v_u8m1
really.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #9 from JuzheZhong ---
(In reply to Andrew Pinski from comment #7)
> .
Besides, if we remove the data initialization:
https://godbolt.org/z/qcjcP7s1c
#include
vuint8m1_t fn() {
uint8_t arr[32];
uint8_t m = 1;
vuint8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #8 from JuzheZhong ---
(In reply to Andrew Pinski from comment #6)
> I suspect if __riscv_vle8_v_u8m1 gets lowered into a load on the gimple
> level, it might just work ...
>
> But it gets expanded as:
> (insn 14 13 0 (set (reg/v:RV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-10-07
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #6 from Andrew Pinski ---
I suspect if __riscv_vle8_v_u8m1 gets lowered into a load on the gimple level,
it might just work ...
But it gets expanded as:
(insn 14 13 0 (set (reg/v:RVVM1QI 134 [ varrD.56526 ])
(if_then_else:RV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #5 from JuzheZhong ---
Similar issue in GCC 13.2:
https://godbolt.org/z/axKc4qj47
fn:
lui a5,%hi(.LANCHOR0)
addia5,a5,%lo(.LANCHOR0)
ld a1,0(a5)
ld a2,8(a5)
ld a3,16(a5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #4 from JuzheZhong ---
I found this is not because VLS modes.
with --param=riscv-autovec-preference=fixed-vlmax
disabling VLS modes also see unnecessary load/store:
fn:
lui a5,%hi(.LANCHOR0)
addisp,sp,-32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #3 from JuzheZhong ---
(In reply to Andrew Pinski from comment #2)
> I noticed there is an ABI difference here.
>
> GCC is returning via a store to a0:
> vsm.v v1,0(a0)
>
> While LLVM is returning via v0 .
>
> Which one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #2 from Andrew Pinski ---
I noticed there is an ABI difference here.
GCC is returning via a store to a0:
vsm.v v1,0(a0)
While LLVM is returning via v0 .
Which one is correct?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #1 from JuzheZhong ---
The root cause is unnecessary VLS modes data movement:
(insn 10 9 11 2 (set (reg:V4DI 143)
(mem/u/c:V4DI (reg:DI 142) [0 S32 A128])) "/app/example.c":4:13 1119
{*movv4di}
(nil))
(insn 11 10 12 2
31 matches
Mail list logo
