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
Autho
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
Assign
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
--- 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
--- 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 c
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=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 opt
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
"*movdf_hardfloat
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 set
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=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 a5,
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 long
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: targ
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=98596
Vineet Gupta changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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
Prio
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: n
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)
(if_then
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 exte
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 ex
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=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;
> > > l
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=114729
--- Comment #14 from Vineet Gupta ---
Interim update:
Per discussions [1] [2] with Richard Sandiford, some of the behavior is
fundamental to the "model" heuristics of -fsched-pressure, specially for
in-order cores which benefit from little more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #16 from Vineet Gupta ---
After ECC hack, the issue persists.
Toggles (for cc1plus): -O2 -march=rv64gc_zfa -mabi=lp64d
%sfp is the spill because
-fno-schedule-insns | -fschedule-insns
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: norm
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 commit
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 z
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 t
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 to
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 Gup
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 f
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 ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105733
Vineet Gupta changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115264
Bug ID: 115264
Summary: RISC-V: yet another instance of poor codegen related
to stack (glibc tmpnam.c)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
Vineet Gupta changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 106265, which changed state.
Bug 106265 Summary: RISC-V SPEC2017 507.cactu code bloat due to address
generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
What|Removed |Added
-
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: note
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 jus
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 prer
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=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: gcc.c-torture/execu
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&action=edit
manually reduced src
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&action=edit
asm output ok
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&action=edit
asm output nok
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=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 #13 from Vineet Gupta ---
Then I don't know where the problem actually is ?
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
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=112817
Bug ID: 112817
Summary: RISC-V: RVV: provide a preprocessor macro for VLS
codegen
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pri
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 whe
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 refin
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: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
S
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=110423
Bug ID: 110423
Summary: Redundant constants not gettign eliminated on RISCV.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
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&action=edit
test case (but needs reverting upstream 6508d5e5a1a)
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 pa
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=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 ki
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
--- 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=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 ha
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=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=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&action=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
s
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 --param=riscv-autove
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&action=edit
additional modules
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=113429
Vineet Gupta changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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=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=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 Linu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #12 from Vineet Gupta ---
Interim update as I unpack sched1.
There's the "main" scheduling algorithm which involves 4 queues and an FSM but
can be ignored for this update.
There's "model" schedule which is the pressure sensitive su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115450
Vineet Gupta changed:
What|Removed |Added
CC||jeffreyalaw at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115450
--- Comment #4 from Vineet Gupta ---
-Ofast -flto=auto -march=rv64gcv_zvl256b_zba_zbb_zbs_zicond_zfa
-ftree-vectorize -mrvv-vector-bits=zvl
For RISC-V issue only happens in a LTO build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115687
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #13 from Vineet Gupta ---
So after many months on and off on the issue, I think I understand what's going
on.
There are 3 insns involved in the issue which sched1 current generates in
following order:
insn 46(1) srliw a0,a5,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #20 from Vineet Gupta ---
The model schedule change (at tweak9) seems stable and showing very promising
result.
The hottest basic block's reg pressure drops down significantly
;; Pressure summary (bb 206): GR_REGS:313 FP_REGS:946
;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #21 from Vineet Gupta ---
The code is currently pushed to
https://github.com/vineetgarc/gcc/commits/topic-sched1/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
--- Comment #2 from Vineet Gupta ---
For other benign instances of the pattern lshrv8qi3, typically it goes through
a splitter in autovec.md which converts it into the canonical RVV form with all
the VL info.
(define_insn_and_split "3"
[(set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
Bug ID: 117353
Summary: RISC-V: ICE when building libcrypt
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
Vineet Gupta changed:
What|Removed |Added
CC||ewlu at rivosinc dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
--- Comment #4 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #3)
> That doesn't make sense. The can_create_pseudo_p() check should have
> prevented this from matching once reload has started.
>
> Does the insn exist in the .i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
Vineet Gupta changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #17 from Vineet Gup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #18 from Vineet Gupta ---
Next macro issue is in different sub-algorithm of scheduler.
module schedule is a simplistic algorithm run ahead of list schedular to get
max pressure which is subsequently used for bounding the list sched
1 - 100 of 158 matches
Mail list logo
