a1,zero,.L4
li a5,0
li a0,0
.L3:
addwa4,a2,a5
addwa5,a3,a5
addwa0,a4,a0
bltua5,a6,.L3
ret
.L4:
li a0,0
ret
```
Signed-off-by: Vineet Gupta
Co-developed-by: Robin Dapp
---
gcc/expr.cc
On 9/28/23 20:17, Jeff Law wrote:
I can bootstrap & regression test alpha using QEMU user mode
emulation. So we might be able to trigger something that way. It'll
take some time, but might prove fruitful.
That would be awesome. It's not like this this is burning or anything
and one of the
On 9/11/23 06:12, Jeff Law via Gcc-patches wrote:
On 9/10/23 21:42, juzhe.zh...@rivai.ai wrote:
Ping this patch.
I think it's time to enable scalable vectorization by default and do
the whole regression every time (except vect.exp that we didn't
enable yet)
Update current FAILs status:
On 9/28/23 12:52, Vineet Gupta wrote:
On 9/28/23 05:53, Jeff Law wrote:
Vineet -- assuming Vlad's patch goes in, the other obvious candidate
for this would be the mvconst_internal define_insn_and_split where
we'd probably want to reject the insn as a whole once IRA has starte
On 9/29/23 05:14, Jeff Law wrote:
On 9/28/23 21:49, Vineet Gupta wrote:
On 9/28/23 20:17, Jeff Law wrote:
I can bootstrap & regression test alpha using QEMU user mode
emulation. So we might be able to trigger something that way. It'll
take some time, but might prove fruitful
On 10/4/23 10:59, Jeff Law wrote:
On 9/28/23 15:43, Vineet Gupta wrote:
RISC-V suffers from extraneous sign extensions, despite/given the ABI
guarantee that 32-bit quantities are sign-extended into 64-bit
registers,
meaning incoming SI function args need not be explicitly sign extended
(so
cv.md (mvconst_internal): Add !ira_in_progress.
Suggested-by: Jeff Law
Signed-off-by: Vineet Gupta
---
changes since v1:
- Fix bug: new condition to prevent recognition not splitting itself
---
gcc/config/riscv/riscv.md | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git
cv.md (mvconst_internal): Add !ira_in_progress.
Suggested-by: Jeff Law
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv.md | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index 1ebe8f92284d..da84b9357bd3 1
On 10/6/23 11:22, Vineet Gupta wrote:
Vlad recently introduced a new gate @ira_in_progress, similar to
counterparts @{reload,lra}_in_progress.
Use this to hide the constant synthesis splitter from being recog* ()
by IRA register equivalence logic which is eager to undo the splits,
generating
On 10/9/23 13:46, Christoph Müllner wrote:
Given that this causes repeated issues, I think that a fall-back to
counting occurrences is the right thing to do. I can do that if that's ok.
Thanks Christoph.
-Vineet
On 10/11/23 19:37, Hans-Peter Nilsson wrote:
```
foo2:
sext.w a6,a1 <-- this goes away
beq a1,zero,.L4
li a5,0
li a0,0
.L3:
addwa4,a2,a5
addwa5,a3,a5
addwa0,a4,a0
bltua5,a6,.L3
re
Hi Kito, Christoph, Patrick,
I've been trying to test a specific non multilib config
(rv64-zicond_zfa) and seeing noisy output (compared to a similar multlib
build) and it seems there's still a bunch of this header issue (for the
rv32 abi headers) in the non-multlib config.
e.g.
FAIL: gcc.dg
rget/riscv/flt-snan.c: Ditto.
* gcc.target/riscv/fltf-ieee.c: Ditto.
* gcc.target/riscv/fltf-snan.c: Ditto.
Signed-off-by: Vineet Gupta
---
gcc/testsuite/gcc.target/riscv/fle-ieee.c | 3 ++-
gcc/testsuite/gcc.target/riscv/fle-snan.c | 3 ++-
gcc/testsuite/gcc.target/riscv/fle.c
rget/riscv/flt-snan.c: Ditto.
* gcc.target/riscv/fltf-ieee.c: Ditto.
* gcc.target/riscv/fltf-snan.c: Ditto.
Signed-off-by: Vineet Gupta
---
gcc/testsuite/gcc.target/riscv/fle-ieee.c | 3 ++-
gcc/testsuite/gcc.target/riscv/fle-snan.c | 3 ++-
gcc/testsuite/gcc.target/riscv/fle.c
On 10/16/23 21:07, Jeff Law wrote:
On 9/28/23 15:43, Vineet Gupta wrote:
RISC-V suffers from extraneous sign extensions, despite/given the ABI
guarantee that 32-bit quantities are sign-extended into 64-bit
registers,
meaning incoming SI function args need not be explicitly sign extended
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr111466.c: Change to scan-assembler-not
to not detect sext.w.
Signed-off-by: Vineet Gupta
---
gcc/testsuite/gcc.target/riscv/pr111466.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/riscv
SEXT.W.
Signed-off-by: Vineet Gupta
---
Changes since v1:
- Changed function return to be unsigned int
---
gcc/testsuite/gcc.target/riscv/pr111466.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.target/riscv/pr111466.c
b/gcc/testsuite/gcc.target/r
SEXT.W.
Signed-off-by: Vineet Gupta
---
gcc/testsuite/gcc.target/riscv/pr111466.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.target/riscv/pr111466.c
b/gcc/testsuite/gcc.target/riscv/pr111466.c
index 007792466a51..3348d593813d 100644
--- a/gcc/tests
On 5/25/23 13:26, Thomas Schwinge wrote:
I'm pasting a snippet of gcc.log. Issue is indeed triggered by rvv.exp
which needs some love.
I'd intentionally asked to "see a complete 'gcc.log' file where the
ERRORs are visible".
The full log files are humongous - even xz compressed is ~ 7 MB -
On 5/26/23 16:38, Vineet Gupta wrote:
On 5/25/23 13:26, Thomas Schwinge wrote:
I'm pasting a snippet of gcc.log. Issue is indeed triggered by rvv.exp
which needs some love.
I'd intentionally asked to "see a complete 'gcc.log' file where the
ERRORs are visible&q
Hi,
This fixes the current broken multilib testing on trunk.
1/3 is th actual fix
2/3 is preventive and
3/3 is debug aid in case this bites someone else in future.
Thx,
-Vineet
Kito Cheng (1):
RISC-V: Add missing torture-init and torture-finish for rvv.exp
Vineet Gupta (2):
testsuite
early return outside
the torture-{init,finish}
Signed-off-by: Vineet Gupta
---
gcc/testsuite/gcc.misc-tests/i386-prefetch.exp | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/gcc/testsuite/gcc.misc-tests/i386-prefetch.exp
b/gcc/testsuite/gcc.misc-tes
From: Kito Cheng
This is in line with recent test harness expectations and is a
preventive change as it doesn't actually fix any errors.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/rvv.exp: Add torture-init and
torture-finish.
Signed-off-by: Vineet Gupta
---
This was helpful when debugging the recent multilib testsuite failure.
gcc/testsuite:
* lib/torture-options.exp: print the value of non-empty options:
torture_without_loops, torture_with_loops, LTO_TORTURE_OPTIONS.
Signed-off-by: Vineet Gupta
---
gcc/testsuite/lib/torture
On 5/30/23 11:43, Vineet Gupta wrote:
On 5/26/23 16:38, Vineet Gupta wrote:
On 5/25/23 13:26, Thomas Schwinge wrote:
I'm pasting a snippet of gcc.log. Issue is indeed triggered by rvv.exp
which needs some love.
I'd intentionally asked to "see a complete 'gcc.log&#x
On 5/31/23 10:57, Jeff Law wrote:
On 5/31/23 10:25, Vineet Gupta wrote:
Multilib testing on trunk is currently busted (and surprisingly this
affects any/all targets but it seems nobody cares). We currently get the
following splat:
I wouldn't say that nobody cares, it just hasn't
On 5/31/23 11:13, Iain Sandoe wrote:
I do have a multilib problem [with libgomp] on Darwin (which has been noticed
:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109951) but it is not obvious how
the fix proposed would solve this - unless it’s some subtle change in global
content for the mult
On 6/1/23 07:54, Jeff Law wrote:
On 5/31/23 10:25, Vineet Gupta wrote:
From: Kito Cheng
This is in line with recent test harness expectations and is a
preventive change as it doesn't actually fix any errors.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/rvv.exp: Add torture-ini
torture-{init,finish}
Signed-off-by: Vineet Gupta
---
gcc/testsuite/gcc.misc-tests/i386-prefetch.exp | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/gcc/testsuite/gcc.misc-tests/i386-prefetch.exp
b/gcc/testsuite/gcc.misc-tests/i386-prefetch.exp
index ad9e56
This was helpful when debugging the recent multilib testsuite failure.
gcc/testsuite:
* lib/torture-options.exp: print the value of non-empty options:
torture_without_loops, torture_with_loops, LTO_TORTURE_OPTIONS.
Signed-off-by: Vineet Gupta
---
gcc/testsuite/lib/torture
Hi Jeff,
I finally got around to collecting various observations on PR/109279 -
more importantly the state of large constants in RV backend, apologies
in advance for the long email.
It seems the various commits in area have improved the original test
case of 0x1010101_01010101
Before 2e8
Hi Jeff,
Thx for the detailed explanation and insight.
On 6/7/23 16:44, Jeff Law wrote:
With 2e886eef7f2b, define_insn_and_split "*mvconst_internal" recog()
kicks in during cse1, eliding insns for a const_int.
(insn 7 6 8 2 (set (reg:DI 137)
(const_int [0x1010101])) {*mvconst_int
Hi Manolis,
On 7/18/23 11:01, Jeff Law via Gcc-patches wrote:
Vineet @ Rivos has indicated he stumbled across an ICE with the V3
code. Hopefully he'll get a testcase for that extracted shortly.
Yeah, I was trying to build SPEC2017 with this patch and ran into ICE
for several of them with -O
On 7/18/23 21:31, Jeff Law via Gcc-patches wrote:
In a run with -fno-fold-mem-offsets, the same insn 93 is successfully
grok'ed by cprop_hardreg,
| (insn 93 337 522 11 (set (mem/c:DF (plus:DI (reg/f:DI 2 sp)
| (const_int 8 [0x8])) [4 %sfp+-8 S8 A64])
| (const_double:D
0_operand): Add back
const_double.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr110748-1.c: New Test.
* gcc.target/riscv/xtheadfmv-fmv.c: Add '\t' around test
patterns to avoid random string matches.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/pred
On 7/21/23 11:15, Philipp Tomsich wrote:
On Fri, 21 Jul 2023 at 19:56, Vineet Gupta wrote:
DF +0.0 is bitwise all zeros so int x0 store to mem can be used to optimize it.
void zd(double *) { *d = 0.0; }
currently:
| fmv.d.x fa5,zero
| fsd fa5,0(a0)
| ret
With patch
| sd zero,0
* gcc.target/riscv/pr110748-1.c: New Test.
* gcc.target/riscv/xtheadfmv-fmv.c: Add '\t' around test
patterns to avoid random string matches.
Signed-off-by: Vineet Gupta
---
Changes since v1:
- No code changes
- Updated commitlog: typo, "Fixes:" tag
On 7/21/23 11:31, Palmer Dabbelt wrote:
On Fri, 21 Jul 2023 10:55:52 PDT (-0700), Vineet Gupta wrote:
DF +0.0 is bitwise all zeros so int x0 store to mem can be used to
optimize it.
void zd(double *) { *d = 0.0; }
currently:
| fmv.d.x fa5,zero
| fsd fa5,0(a0)
| ret
With patch
| sd
On 7/21/23 11:31, Palmer Dabbelt wrote:
IIUC the pattern to emit fmv suffers from the same bug -- it's fixed
in the same
way, but I think we might be able to come up with a test for it:
`fmv.d.x FREG,
x0` would be the fastest way to generate 0.0, so maybe something like
double sum(doub
On 7/21/23 23:05, Jeff Law wrote:
On 7/21/23 12:30, Vineet Gupta wrote:
Fixes: ef85d150b5963 ("RISC-V: Enable TARGET_SUPPORTS_WIDE_INT")
(gcc-13 regression)
DF +0.0 is bitwise all zeros so int x0 store to mem can be used to
optimize it.
void zd(double *) { *d = 0.0; }
test
patterns to avoid random string matches.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/predicates.md | 2 +-
gcc/testsuite/gcc.target/riscv/pr110748-1.c| 10 ++
gcc/testsuite/gcc.target/riscv/xtheadfmv-fmv.c | 8
3 files changed, 15 insertions(+
pening,
then it's worth investigating why.
Besides that, I have checked the build failure on x264_r. It is
already fixed on the third version.
Yea, this was a problem with re-recognition. I think it was fixed by:
commit ecfa870ff29d979bd2c3d411643b551f2b6915b0
Author: Vineet Gupta
Dat
Hi Jeff,
As discussed this morning, I'm sending over dumps for the optim of DF
const -0.0 (PR/110748) [1]
For rv64gc_zbs build, IRA is undoing the split which eventually leads to
ICE in final pass.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748#c15
void znd(double *d) { *d = -0.0;
On 8/1/23 15:07, Philipp Tomsich wrote:
+Manolis Tsamis
On Tue, 1 Aug 2023 at 23:56, Jeff Law via Gcc-patches
wrote:
On 8/1/23 13:14, Vineet Gupta wrote:
I have some numbers for f-m-o v3 vs this. Attached here (vs. inline to
avoid the Thunderbird mangling the test formatting)
Thanks
case which f-m-o seems to be generating a MV for.
On Wed, 2 Aug 2023 at 01:03, Vineet Gupta wrote:
On 8/1/23 15:07, Philipp Tomsich wrote:
+Manolis Tsamis
On Tue, 1 Aug 2023 at 23:56, Jeff Law via Gcc-patches
wrote:
On 8/1/23 13:14, Vineet Gupta wrote:
I have some numbers for f-m-o
On 8/1/23 16:22, Jeff Law wrote:
They must not be working as expected or folks are using old trees.
Manolis's work for regcprop has been on the trunk for about 5-6 weeks
ag this point:
I have bleeding edge trunk from 2-3 days back. I think we are looking
for the following which the tree d
On 8/1/23 16:27, Jeff Law wrote:
On 8/1/23 17:13, Vineet Gupta wrote:
On 8/1/23 16:06, Philipp Tomsich wrote:
Very helpful! Looks as if regprop for stack_pointer is now either too
conservative — or one of our patches is missing in everyone's test
setup; we'll take a closer lo
Hi Jeff,
On 6/26/22 12:05, Jeff Law via Gcc-patches wrote:
On 5/29/2022 9:53 PM, Vineet Gupta wrote:
These tests validate fp conversions with various rounding modes which
would not work on soft-float ABIs.
On -march=rv64imac/-mabi=lp64 this reduces 5 unique failures (overall 35
due to multi
On 5/29/22 20:50, Kito Cheng via Gcc-patches wrote:
Committed, thanks!
Can this be backported to gcc-12 please.
Thx,
-Vineet
On Fri, May 27, 2022 at 10:37 AM Vineet Gupta wrote:
Commit 9ddd44b58649d1d ("RISC-V: Provide `fmin'/`fmax' RTL pattern") added
tests which
On 8/3/23 11:12, Jeff Law via Gcc-patches wrote:
On Thu, 03 Aug 2023 08:05:09 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
[...]
There's a bigger TODO in this space WRT a top-to-bottom evaluation of
the costing on RISC-V. I'm still formulating what that evaluation is
going to look like, so don'
On 8/3/23 16:15, Jeff Law wrote:
On 8/3/23 16:26, Vineet Gupta wrote:
As discussed in Tue call, I definitely have 1 fix to riscv_rtx_costs
(), which is worth pondering. It adjusts the cost of consts and helps
Hoist GCSE constants (which granted kicks in only at -Os). However it
does
On 8/7/23 13:36, Jeff Law wrote:
Fixes several missed conditional moves with the trunk.
I'm curious, how do you know what's missing. Does ifc have some stats
like autovec which explicitly reports missed opportunities ?
-Vineet
Hi Jeff,
On 8/7/23 13:36, Jeff Law wrote:
This test is too aggressive. Constants have VOIDmode, so we need to
let the through this phase of conditional move support.
Fixes several missed conditional moves with the trunk.
Committed to the trunk,
As discussed this morning, this triggers an
On 8/8/23 13:24, Edwin Lu wrote:
diff --git a/gcc/testsuite/gcc.target/riscv/attribute-1.c
b/gcc/testsuite/gcc.target/riscv/attribute-1.c
index bc919c586b6..4b077c980a4 100644
--- a/gcc/testsuite/gcc.target/riscv/attribute-1.c
+++ b/gcc/testsuite/gcc.target/riscv/attribute-1.c
@@ -2,5 +2,20 @
Hi Jin Ma,
On 5/16/23 00:06, jinma via Gcc-patches wrote:
On 5/15/23 07:16, Jin Ma wrote:
Do we also need to check Z[FDH]INX too?
Otherwise it looks pretty good. We just need to wait for everything to
freeze and finalization on the assembler interface.
jeff
Yes, you are right, we also need
.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/gcse-const.c: New Test
* gcc.target/riscv/rvv/vsetvl/vlmax_conflict-7.c: Disable for
-O2.
* gcc.target/riscv/rvv/vsetvl/vlmax_conflict-8.c: Ditto.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv.cc
On 8/1/23 12:17, Vineet Gupta wrote:
Hi Jeff,
As discussed this morning, I'm sending over dumps for the optim of DF
const -0.0 (PR/110748) [1]
For rv64gc_zbs build, IRA is undoing the split which eventually leads
to ICE in final pass.
[1] https://gcc.gnu.org/bugzilla/show_bug.c
On 8/11/23 17:04, Jeff Law wrote:
I'm wondering (naively) if there is some way to tune this - for a
given backend. In general it would make sense to do the replacement,
but not if the cost changes (e.g. consts could be embedded in x86
insn freely, but not for RISC-V where this is costly and
On 8/18/23 16:08, Jeff Law wrote:
There is some slight regression in code quality for a number of
vector tests where we spill more due to different instructions order.
The ones I looked at were a mix of bad luck and/or brittle tests.
Comparing the size of the generated assembly or the number o
hival computation
do elide subtraction of loval.
* (riscv_split_integer_cost): Ditto.
* (riscv_build_integer): Ditto
Signed-off-by: Vineet Gupta
---
I wasn't planning to do any more work on large const stuff, but just ran into
it this
on a random BZ entry when tr
On 6/30/23 16:33, Vineet Gupta wrote:
Ran into a minor snafu in const splitting code when playing with test
case from an old PR/23813.
long long f(void) { return 0xF0F0F0F0F0F0F0F0ull; }
This currently generates
li a5,-252645376
addia5,a5,241
li
elf-gcc -O2 test.c
$ spike pk a.out
bbl loader
f0f0f0eff0f0f0f0
$
Thx for the quick feedback Andew. I'm clearly lacking in signed math :-(
So is it possible to have a better code seq for the testcase at all ?
-Vineet
On Fri, Jun 30, 2023 at 4:42 PM Vineet Gupta wrote:
On 6/30/23
On 10/19/23 23:50, Ajit Agarwal wrote:
Hello All:
This version 9 of the patch uses abi interfaces to remove zero and sign
extension elimination.
Bootstrapped and regtested on powerpc-linux-gnu.
In this version (version 9) of the patch following review comments are
incorporated.
a) Removal of
as in whenever abi interfaces code identifies
and extension (saw missing a definition, the it is not able to eliminate
any extensions despite the patch.
-Vineet
[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632180.html
On 22/10/23 12:56 am, rep.dot@gmail.com wrote:
On 21
On 10/24/23 10:03, Ajit Agarwal wrote:
Hello Vineet, Jeff and Bernhard:
This version 14 of the patch uses abi interfaces to remove zero and sign
extension elimination.
This fixes aarch64 regressions failures with aggressive CSE.
Once again, this information belong between the two "---" lin
On 10/24/23 13:36, rep.dot@gmail.com wrote:
As said, I don't see why the below was not cleaned up before the V1 submission.
Iff it breaks when manually CSEing, I'm curious why?
The function below looks identical in v12 of the patch.
Why didn't you use common subexpressions?
ba
Using CSE her
og:
* config/riscv/riscv.cc (riscv_extend_comparands): Don't
sign-extend operand if subreg promoted with inner word size.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv.cc | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/gcc/config/riscv/ri
Hey Robin,
On 10/25/23 00:12, Robin Dapp wrote:
Hi Vineet,
I was thinking of two things while skimming the code:
- Couldn't we do this in the expanders directly? Or is the
subreg-promoted info gone until we reach that?
Following is the call stack involved:
expand_gimple_cond
do
On 10/25/23 09:30, Jeff Law wrote:
- Should some common-code part be more suited to handle that?
We already elide redundant sign-zero extensions for other
reasons. Maybe we could add subreg promoted handling there?
Not in the context of this specific issue.
Robin's point (IIUC) is
On 10/25/23 06:52, Jeff Law wrote:
On 10/25/23 07:47, Robin Dapp wrote:
Well, it doesn't seem like there's a lot of difference between doing
it in the generic expander bits vs target expander bits -- the former
just calls into the latter for the most part. Thus if the
subreg-promoted stat
On 10/24/23 22:01, Vineet Gupta wrote:
RV64 comapre and branch instructions only support 64-bit operands.
The backend unconditionally generates zero/sign extend at Expand time
for compare and branch operands even if they are already as such
e.g. function args which ABI guarantees to be sign
On 10/27/23 10:16, Bernhard Reutner-Fischer wrote:
On Wed, 25 Oct 2023 16:41:07 +0530
Ajit Agarwal wrote:
On 25/10/23 2:19 am, Vineet Gupta wrote:
On 10/24/23 13:36, rep.dot@gmail.com wrote:
As said, I don't see why the below was not cleaned up before the V1 submission.
Iff it b
nds): Call New function on operands.
Signed-off-by: Vineet Gupta
---
Changes since v1:
- Elide sign extension for 32-bit operarnds only
- Apply elison for both arguments
---
gcc/config/riscv/riscv.cc | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/gcc
On 10/29/23 19:04, Vineet Gupta wrote:
RV64 compare and branch instructions only support 64-bit operands.
At Expand time, the backend conservatively zero/sign extends
its operands even if not needed, such as incoming 32-bit function args
which ABI/ISA guarantee to be sign-extended already
nds): Call New function on operands.
Signed-off-by: Vineet Gupta
---
Changes since v2:
- Fix linting issues flagged by pre-commit CI
Changes since v1:
- Elide sign extension for 32-bit operarnds only
- Apply elison for both arguments
---
gcc/config/riscv/riscv.cc | 23 +--
On 10/30/23 13:33, Jeff Law wrote:
On 10/29/23 21:21, Vineet Gupta wrote:
RV64 compare and branch instructions only support 64-bit operands.
At Expand time, the backend conservatively zero/sign extends
its operands even if not needed, such as incoming 32-bit function args
which ABI/ISA
ix mode
returned for libcall case.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv.cc | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 3e27897d6d30..7b8e9af0a5af 100644
--- a/gcc/config/riscv/riscv.cc
+
On 10/30/23 16:21, Vineet Gupta wrote:
I don't guess you have data on how this impacts dynamic instruction
counts on anything significant do you?
No, haven't run it yet. I can fire one though. I doubt if this is as
significant as the prev one, even if this is the right thing to d
On 10/30/23 13:33, Jeff Law wrote:
+/* Helper function for riscv_extend_comparands to Sign-extend the OP.
+ However if the OP is SI subreg promoted with an inner DI, such as
+ (subreg/s/v:SI (reg/v:DI) 0
+ just peel off the SUBREG to get DI, avoiding extraneous
extension. */
+
+sta
On 10/31/23 17:51, Jeff Law wrote:
We also have a non-orthogonality in the ABI sign extension rules
between SI and DI, a few of us were talking about it on the internal
slack (though the specifics were for a different patch, Vineet has a
few in flight).
So the old issue I was thinking of
On 11/1/23 12:11, Jeff Law wrote:
On 10/31/23 12:35, Vineet Gupta wrote:
riscv_promote_function_mode doesn't promote a SI to DI for libcalls
case.
The fix is what generic promote_mode () in explow.cc does. I really
don't understand why the old code didn't work, but st
og:
* config/riscv/riscv.cc (riscv_promote_function_mode): Fix mode
returned for libcall case.
Tested-by: Patrick O'Neill # pre-commit-CI #526
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv.cc | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/config/ri
gcc.target/riscv/pr108987.c: New test.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv.cc | 3 ++-
gcc/testsuite/gcc.target/riscv/pr108987.c | 9 +
gcc/testsuite/gcc.target/riscv/zba-shNadd-07.c | 6 +++---
3 files changed, 14 insertions(+), 4 deletions(-)
c
On 5/16/23 16:06, Palmer Dabbelt wrote:
A few of us were talking about test-related issues in the patchwork
meeting
this morning. I bumped to trunk and did a full rebuild, I'm getting the
following (it's in riscv-systems-ci/riscv-gnu-toolchain). This is
about what I
remember seeing last time
+ Christoph, Jiawei
On 5/16/23 17:20, Palmer Dabbelt wrote:
We really need to add some CI around RV toolchains to trip on these
sooner !
Sounds like you're volunteering to set one up?
Patrick's github CI patch seems to be a great start. Lets wait for it to
get merged, that will at least ca
On 5/16/23 18:29, Palmer Dabbelt wrote:
On Tue, 16 May 2023 18:04:37 PDT (-0700), Vineet Gupta wrote:
+ Christoph, Jiawei
On 5/16/23 17:20, Palmer Dabbelt wrote:
We really need to add some CI around RV toolchains to trip on these
sooner !
Sounds like you're volunteering to set o
On 5/16/23 19:21, Kito Cheng wrote:
Palmer:
For short-term, this should help your internal test:
https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1233
That only helps if using bleeding edge toolchain scripts (which I
regularly do and so did Patrick).
Palmer has a fork of toolchain s
On 5/16/23 19:53, Palmer Dabbelt wrote:
Probably, I'll go try and bump stuff and see if it works...
Word of caution: Best to not disturb your existing setup, a try a fresh
checkout first
/riscv/riscv.cc (riscv_split_integer): if loval is equal
to hival, ASHIFT the corresponding regs.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv.cc | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv
On 5/17/23 00:52, Andreas Schwab wrote:
On Mai 16 2023, Vineet Gupta wrote:
Yes I was seeing similar tcl errors and such - and in my case an even
higher count.
They are coming from commit d6654a4be3b.
As of a726d007f197 today I get a gazzilion splat for riscv multilib
dejagnu runs and
On 5/19/23 09:36, Palmer Dabbelt wrote:
Works for me. Did you start that performance backports branch?
Either way, I think this should go on it.
Please note that there is a bit of dependency chain. Assuming the
aforementioned branch is gcc 13.1 based, this change also needs my
splitter r
On 5/19/23 09:33, Jeff Law wrote:
On 5/18/23 14:57, Vineet Gupta wrote:
[part #2 of PR/109279]
SPEC2017 deepsjeng uses large constants which currently generates
less than
ideal code. This fix improves codegen for large constants which have
same low and hi parts: e.g.
long long f(void
On 5/22/23 02:17, Kito Cheng wrote:
Ooops, seems still some issue around here,
Yep still 5000 fails :-(
but I found something might
related this issue:
https://github.com/gcc-mirror/gcc/commit/d6654a4be3ba44c0d57be7c8a51d76d9721345e1
https://github.com/gcc-mirror/gcc/commit/23c49bb8d09bc3b
+CC Thomas and Maciej
On 5/22/23 20:52, Vineet Gupta wrote:
On 5/22/23 02:17, Kito Cheng wrote:
Ooops, seems still some issue around here,
Yep still 5000 fails :-(
but I found something might
related this issue:
https://github.com/gcc-mirror/gcc/commit
On 5/24/23 13:34, Thomas Schwinge wrote:
Yeah, at this point I'm not sure whether my recent changes really are
related/relevant here.
Apparently in addition to Kito's patch below, If I comment out the
additional torture options, failures go down drastically.
Meaning that *all* those ERRORs dis
On 5/24/23 15:13, Vineet Gupta wrote:
PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects (test for excess errors)
PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects scan-assembler-times mul\t 1
PASS: gcc.target/riscv
Hi Thomas,
On 5/25/23 13:56, Thomas Schwinge wrote:
Hi!
On 2022-02-08T00:22:37+0800, Kito Cheng via Gcc-patches
wrote:
Hi Maciej:
Thanks for doing this, OK to trunk.
On Tue, Feb 1, 2022 at 7:04 AM Maciej W. Rozycki wrote:
Use `gcc-dg-runtest' test driver rather than `dg-runtest' to run t
On 5/25/23 14:17, Vineet Gupta wrote:
FWIW if you want to test this out at your end, it is super easy.
|git clone https://github.com/riscv-collab/riscv-gnu-toolchain
toolchain-upstream cd toolchain-upstream git submodule init git
submodule update ||./configure --with-arch=rv64imafdc --with
On 5/25/23 13:29, Thomas Schwinge wrote:
Hi!
On 2023-05-17T09:52:13+0200, Andreas Schwab via Gcc-patches
wrote:
On Mai 16 2023, Vineet Gupta wrote:
Yes I was seeing similar tcl errors and such - and in my case an even
higher count.
They are coming from commit d6654a4be3b.
I call FUD
On 5/25/23 14:17, Vineet Gupta wrote:
Thanks for taking a look at this. Please don't get me wrong, never
mean to vilify the patches above - and I should have verified first
(by reverting those) if they caused the issue - if at all. It just
seemed that we started seeing these relat
1 - 100 of 360 matches
Mail list logo
