https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118019
--- Comment #14 from Vineet Gupta ---
(In reply to Robin Dapp from comment #7)
> > The problem is GCC-15 has performance regression compare to GCC-14 on both
> > strict align and we should fix it, we can't specify use no strict align in
> > GCC-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117990
--- Comment #11 from Vineet Gupta ---
FWIW cam4 is still failing with similar symptoms. So perhaps it is something
else.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118019
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #8 from Vineet Gupta ---
(In reply to JuzheZhong from comment #7)
> I think Phase 3 early fusion should handle this scenario.
It is handling this, except that it fusing the 2nd into 1st which happens to be
before the BEQ, hence this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117990
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117722
--- Comment #16 from Vineet Gupta ---
(In reply to Robin Dapp from comment #15)
> (In reply to Vineet Gupta from comment #14)
> > @Robin, it seems the current codegen generates 2 widening ops, which might
> > not be as efficient. We have done s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #6 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #5)
> What's starting to rattle around in my brain is the for a loop, if the count
> is unknown, then we probably don't want to unroll as that's much more likely
> to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #4 from Vineet Gupta ---
(In reply to JuzheZhong from comment #2)
> We need to split all insns since some of them are not the ultimate RVV
> instruction pattern that depend on VL/VTYPE.
> And I don't think the vsetvli should be keep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117722
--- Comment #14 from Vineet Gupta ---
(In reply to Li Pan from comment #7)
> Created attachment 59661 [details]
> with usad pattern
Can you please post the patch, lest we duplicate your effort.
It would be nice to test it on real hardware.
@Ro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #1 from Vineet Gupta ---
So the way things seem to work here are in cprop_hardreg (just before vsetvl)
we have following:
(insn 44 18 47 4 (set (reg:DI 15 a5 [orig:139 _31 ] [139])
(unspec:DI [
(reg:DI 11 a1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
Bug ID: 117974
Summary: RISC-V: VSETVL hoisting across branch
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117733
--- Comment #3 from Vineet Gupta ---
"C" reproducer...
void bar(double);
void foo(double q[][5], int nx)
{
int i, l;
double dqnorm = 0.0;
for (i=0; i < nx; i++) {
for (l=0; l<5; l++) {
dqnorm = dqnorm + q[i][l]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
--- Comment #13 from Vineet Gupta ---
(In reply to Vineet Gupta from comment #12)
> Two years hence and we are a little wiser.
>
> The root-cause of spills is sched1
> [PR/114729](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729).
With abov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117733
--- Comment #1 from Vineet Gupta ---
Tree vec pass is introducing the following MASK_LEN_LOAD and COND_LEN_ADD
constructs.
vect__31.15_91 = .MASK_LEN_LOAD (vectp_q.13_99, 64B, { -1, -1, -1, -1 },
_92(D), loop_len_97, 0);
vectp_q.13_90 = vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117733
Bug ID: 117733
Summary: RISC-V SPEC2017 503.bwaves Inefficient fortran
multi-dimensional array access
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
--- Comment #9 from Vineet Gupta ---
Or the other option is to prevent these patterns from kicking in during reload
by adjust the costs (there's a TODO there already)
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 3ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
--- Comment #8 from Vineet Gupta ---
We could potentially use a scratch in splitter.
(clobber (match_scratch:DI 3 "=&r"))]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
--- Comment #7 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #6)
> So my approach would be to note the insn number, then set a conditional
> breakpoint in make_insn_raw (after it initializes INSN_UID in the new
> insn). The co
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=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=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=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 #19 from Vineet Gupta ---
For last several weeks I've been working on various tweaks to address the model
schedule issue. It seems conceptually really simple, something along the lines
of following:
for (;;)
{
FOR_EACH_DE
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
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 #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=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 #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
--- 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=115687
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment #
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=115450
Vineet Gupta changed:
What|Removed |Added
CC||jeffreyalaw at gmail dot com,
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=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=106265
Vineet Gupta changed:
What|Removed |Added
Status|UNCONFIRMED |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=105733
Vineet Gupta changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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 #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
--- 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
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=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=112817
Vineet Gupta changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
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=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=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=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
--- 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 #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 #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 #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
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=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=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 #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
--- 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
--- 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
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment #
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=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=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
--- 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=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=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
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment #
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=111557
Vineet Gupta changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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=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=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
Vineet Gupta changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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
--- 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 #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 #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=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
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 #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=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=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=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=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=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 ex
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=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=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=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=98596
Vineet Gupta changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=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=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=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,
1 - 100 of 119 matches
Mail list logo
