https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98596
Vineet Gupta changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311
--- Comment #9 from Vineet Gupta ---
(In reply to Patrick O'Neill from comment #8)
> Updated regression list using r14-5070-g4ea36076d66 on rv64gcv:
>
> Failure list from:
> https://github.com/patrick-rivos/gcc-postcommit-ci/issues/109
And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311
--- Comment #11 from Vineet Gupta ---
(In reply to Robin Dapp from comment #10)
> As a general remark: Some of those are present on other backends as well,
> some have been introduced by recent common-code changes and some are bogus
> test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111791
--- Comment #5 from Vineet Gupta ---
(In reply to Robin Dapp from comment #4)
> Analyzing loop at pr111791.c:8
> pr111791.c:8:25: note: === analyze_loop_nest ===
> pr111791.c:8:25: note: === vect_analyze_loop_form ===
> pr111791.c:8:25:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111466
Vineet Gupta changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111466
--- Comment #2 from Vineet Gupta ---
(In reply to Vineet Gupta from comment #1)
> #1. REE reports failure as "missing definition(s)".
>
> This is because function args don't have an explicit def, they are just
> there.
>
> Cannot eliminate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111466
--- Comment #1 from Vineet Gupta ---
So there are various aspects to tackling this issue.
#1. REE reports failure as "missing definition(s)".
This is because function args don't have an explicit def, they are just there.
Cannot eliminate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111467
Bug ID: 111467
Summary: REE failing to eliminate redundant extension due to
multiple reaching def(s)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111466
Bug ID: 111466
Summary: RISC-V: redundant sign extensions despite ABI
guarantees
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111467
--- Comment #1 from Vineet Gupta ---
(insn 8 4 11 2 (set (reg:SI 15 a5 [orig:137 b ] [137]) <--- DEF #1
(reg:SI 11 a1 [orig:136 b ] [136])) "max.c":12:20 207 {*movsi_internal}
(nil))
(jump_insn 11 8 22 2 (set (pc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #18 from Vineet Gupta ---
(In reply to Vineet Gupta from comment #17)
> (In reply to Vineet Gupta from comment #16)
> > > Which is what this produces:
> > > ```
> > > long long f(void)
> > > {
> > > unsigned t = 16843009;
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #19 from Vineet Gupta ---
FWIW with today's change, splitter is now hidden from IRA, but we are still
getting the extraneous mv.
2023-10-06 c1bc7513b1d7 RISC-V: const: hide mvconst splitter from IRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39
Bug ID: 39
Summary: RISC-V: improve scalar constants cost model
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39
--- Comment #2 from Vineet Gupta ---
Test case to help drive some of this:
unsigned long long f5(unsigned long long i)
{
return i * 0x0202020202020202ULL;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #16 from Vineet Gupta ---
(In reply to Vineet Gupta from comment #15)
> On the branch devel/vineetg/optim-double-const-m0 I have double -0.0 working.
>
> znd:
> li a5,-1
> sllia5,a5,63
> sd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #17 from Vineet Gupta ---
(In reply to Vineet Gupta from comment #16)
> > Which is what this produces:
> > ```
> > long long f(void)
> > {
> > unsigned t = 16843009;
> > long long t1 = t;
> > long long t2 = ((unsigned long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #4 from Vineet Gupta ---
Created attachment 56541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56541=edit
asm output nok
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #3 from Vineet Gupta ---
Created attachment 56540
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56540=edit
asm output ok
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
Bug ID: 112447
Summary: risc-v regression: FAIL:
gcc.c-torture/execute/memset-3.c -O3
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #2 from Vineet Gupta ---
Created attachment 56539
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56539=edit
manually reduced src
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311
--- Comment #16 from Vineet Gupta ---
(In reply to Patrick O'Neill from comment #8)
> Updated regression list using r14-5070-g4ea36076d66 on rv64gcv:
>
> === gcc: Unexpected fails for rv64gcv lp64d medlow ===
> FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #6 from Vineet Gupta ---
I have debugged this by single stepped in qemu
when the test fails (first loop for offset 0, iteration 8)
The last VSETVLI is this one,
0x10a3e 0d107057 vsetvli zero,zero,e32,m2,ta,ma
0x10a42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
Vineet Gupta changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109574
Bug ID: 109574
Summary: RISC-V: gcc.dg/pr90838.c failing due to extra ANDI 127
on releases/gcc-13
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888
--- Comment #3 from Vineet Gupta ---
Debugging of ctz3 case
The insns of interest are:
insn_cost 4 for 6: r74:SI=ctz(r73:DI#0)
REG_DEAD r73:DI
insn_cost 4 for 7: r72:DI=sign_extend(r74:SI)
REG_DEAD r74:SI
Before the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888
--- Comment #9 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #6)
> Comment on attachment 54905 [details]
> proposed patch
>
> So that's a subset of what we've done. We initially thought that was going
> to be enough to solve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888
--- Comment #7 from Vineet Gupta ---
(In reply to Roger Sayle from comment #5)
> Created attachment 54905 [details]
> proposed patch
>
> This patch should fix this problem, by adding another pattern the machine
> description to also recognize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #3 from Vineet Gupta ---
Indeed the constraint already exists
(define_insn "*movdf_hardfloat_rv64"
[(set (match_operand:DF 0 "nonimmediate_operand" "=f,f,f,m,m,*f,*r,
*r,*r,*m")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
Vineet Gupta changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
Bug ID: 110748
Summary: optimize store of DF 0.0
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #8 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #5)
> I'd bet it's const_0_operand not allowing CONST_DOUBLE.
Correct.
> The question is what unintended side effects we'd have if we allowed
> CONST_DOUBLE 0.0 in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #9 from Vineet Gupta ---
(In reply to Vineet Gupta from comment #8)
> (In reply to Jeffrey A. Law from comment #5)
> > I'd bet it's const_0_operand not allowing CONST_DOUBLE.
>
> Correct.
>
> > The question is what unintended side
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110423
--- Comment #3 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #2)
> This is derived heavily from Click's work in the 90s.
> This would happen in gimple most likely, though I guess one could do it in
> RTL if they have a high
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #15 from Vineet Gupta ---
(In reply to Vineet Gupta from comment #12)
> > void znd(double *d) { *d = -0.0; }
> > void znf(float *f) { *f = -0.0; }
We need 3 set of changes to get const -0.0 working:
1. Allow expand to generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #10 from Vineet Gupta ---
The fix for handling +0.0 is posted to list - really trivial.
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625217.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #11 from Vineet Gupta ---
There's a variation which can be optimized as well and seems non trivial to
implement
Now it is the negative constant -0.0 to be stored to mem. In bit notation this
has a single sign bit set thus can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #12 from Vineet Gupta ---
> void znd(double *d) { *d = -0.0; }
> void znf(float *f) { *f = -0.0; }
The rough approach I'm thinking of is to
(1) Introduce a constraint for -0.0 and perhaps a predicate as well for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110423
--- Comment #1 from Vineet Gupta ---
Created attachment 55402
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55402=edit
test case (but needs reverting upstream 6508d5e5a1a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110423
Bug ID: 110423
Summary: Redundant constants not gettign eliminated on RISCV.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #16 from Vineet Gupta ---
> Which is what this produces:
> ```
> long long f(void)
> {
> unsigned t = 16843009;
> long long t1 = t;
> long long t2 = ((unsigned long long )t) << 32;
> asm("":"+r"(t1));
> return t1 | t2;
> }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113570
--- Comment #1 from Vineet Gupta ---
This one is a headache as we don't know where the problem is. And that it takes
~7hr for a QEMU run to finish.
Good this is there is a comparison point as VLA build works fine.
(1). bloat-o-meter (from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113570
Bug ID: 113570
Summary: RISC-V: SPEC2017 549 fotonik3d miscompilation in
autovec VLS 256 build
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #18 from Vineet Gupta ---
(In reply to JuzheZhong from comment #17)
> PLCT told me they passed with zvl256b.
>
> I always run SPEC with FIXED-VLMAX since we always care about peak
> performance
> on our board.
Sure we all have our
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #16 from Vineet Gupta ---
(In reply to JuzheZhong from comment #15)
> Currently, we don't have much run FAIL and ICE left in full coverage testing.
>
> I suspect it is very corner case in SPEC.
>
> You don't have to debug it. Just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #14 from Vineet Gupta ---
(In reply to Vineet Gupta from comment #13)
> (In reply to JuzheZhong from comment #12)
> > (In reply to Patrick O'Neill from comment #11)
> > > (In reply to Patrick O'Neill from comment #10)
> > > > I've
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105733
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
--- Comment #9 from Vineet Gupta ---
(In reply to JuzheZhong from comment #5)
> Support VLS codegen with -mrvv-vector-bits and attribute is reasonable to be
> landed on GCC-14.
>
> Could you first implement -mrvv-vector-bits feature ?
>
> I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113429
Bug ID: 113429
Summary: RISC-V: SPEC2017 527 cam4 miscompilation in autovec
VLA build
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113429
--- Comment #1 from Vineet Gupta ---
Created attachment 57107
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57107=edit
Reduced cam4 test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113429
--- Comment #2 from Vineet Gupta ---
Here's my analysis as to whats going on in vsetvl pass.
Reduced Test with annotated BBs.
.globl __a_MOD_f
.type __a_MOD_f, @function
__a_MOD_f:
...
ble s1,zero,.L49
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113429
--- Comment #3 from Vineet Gupta ---
The toggles used to build are
riscv64-unknown-linux-gnu-gfortran -c -o cam4red.o -I. -Iinclude
-Inetcdf/include -Ofast -fno-lto -static -march=rv64gcv_zba_zbb_zbs_zicond
-ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113429
--- Comment #8 from Vineet Gupta ---
Thx for the quick fix. I'll validate and commit !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 113429, which changed state.
Bug 113429 Summary: RISC-V: SPEC2017 527 cam4 miscompilation in autovec VLA
build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113429
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113429
Vineet Gupta changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
--- Comment #13 from Vineet Gupta ---
Yeah Greg from Rivos started working on it. He'll update here as he makes
progress.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112651
--- Comment #4 from Vineet Gupta ---
(In reply to JuzheZhong from comment #3)
> The reason we use --param=riscv-autovec-lmul instead of -mvect-lmul which is
> not documented because we don't have ratifed compile option.
>
> I have mentioned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
Bug ID: 112817
Summary: RISC-V: RVV: provide a preprocessor macro for VLS
codegen
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
--- Comment #6 from Vineet Gupta ---
(In reply to JuzheZhong from comment #5)
> Support VLS codegen with -mrvv-vector-bits and attribute is reasonable to be
> landed on GCC-14.
I don't think that is the reqmt for this issue. Just defining the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112853
--- Comment #2 from Vineet Gupta ---
Bisected to
commit 97ddebb6b4f6b132b0a8072b26d030077b418963
Author: Juzhe-Zhong
Date: Thu Nov 23 18:55:03 2023 +0800
RISC-V: Refine some codes of riscv-v.cc[NFC]
This patch is NFC patch to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112853
--- Comment #1 from Vineet Gupta ---
Currently bisecting.
The issue happens at an indexed load insn:
=> 0x6f656 :vluxei64.v v2,(a3),v2
The src reg v2 is different in good vs. failing case
bad case
--
info reg v2
b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112853
Bug ID: 112853
Summary: RISC-V: RVV: SPEC2017 525.x264 regression
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
Vineet Gupta changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111557
Vineet Gupta changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #11 from Vineet Gupta ---
As a hack I commented out set_delete() to see what the extraneous vsetvli
would have been.
```
.L36:
# bb 3: start of outer loop: off 0
vsetvli zero,zero,e8,mf2,ta,ma # insn 2915
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #15 from Vineet Gupta ---
(In reply to JuzheZhong from comment #14)
> Let me give you some guide which helps you to dig into the problem.
>
> First, reduce the case as follows:
Did your msg get truncated or pressed send too soon ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #13 from Vineet Gupta ---
Then I don't know where the problem actually is ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113429
--- Comment #6 from Vineet Gupta ---
Created attachment 57111
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57111=edit
additional modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
Vineet Gupta changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
--- Comment #15 from Vineet Gupta ---
(In reply to Vineet Gupta from comment #14)
> 2. implement gcc toggle -mrvv-vector-bits=zvl which essentially copies the
> xxx from -march string
Done:
commit 0a01d1232ff0a8b094270fbf45c9fd0ea46df19f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
Vineet Gupta changed:
What|Removed |Added
Last reconfirmed|2024-04-15 00:00:00 |2024-4-16
--- Comment #9 from Vineet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #10 from Vineet Gupta ---
Debug update -fsched-verbose=99 dumps (they are reay verbose)
For the insn/regs under consideration, the canonical pre-scheduled sequence
with ideal live-range (but non-ideal load-to-use delay) is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
Bug ID: 114729
Summary: RISC-V SPEC2017 507.cactu excessive spillls with
-fschedule-insns
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #2 from Vineet Gupta ---
FWIW -fsched-pressure is already default enabled for RISC-V.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #4 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #3)
> Vineet, do we have this isolated enough that we know what function is most
> affected and presumably the most impacted blocks? If so we can probably
> start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111501
--- Comment #4 from Vineet Gupta ---
Awesome !
The trunk is open and new stuff, RISC-V certainly, is already landing, so no
harm in sending it now ;-)
80 matches
Mail list logo
