On 9/18/23 19:41, Jeff Law wrote:
On 9/18/23 13:45, Vineet Gupta wrote:
For the cases which do require sign extends, but not being eliminated
due to "missing definition(s)" I'm working on adapting Ajit's REE ABI
interfaces work [2] to work for RISC-V as well.
I wonder if we
On 9/18/23 19:41, Jeff Law wrote:
On 9/18/23 13:45, Vineet Gupta wrote:
For the cases which do require sign extends, but not being eliminated
due to "missing definition(s)" I'm working on adapting Ajit's REE ABI
interfaces work [2] to work for RISC-V as well.
I wonder if we
On 9/18/23 09:11, Jeff Law wrote:
On 9/18/23 09:24, Kito Cheng wrote:
I may missed that one time too, not on plane yet, but need to go bed
earlier due to my flight is in next day early morning...
I'm unavailable as well, though I don't get on a plane until Wednesday
evening.
This is one
Hi Ajit,
On 9/17/23 22:59, Ajit Agarwal wrote:
This new version of patch 6 use improve ree pass for rs6000 target using
defined ABI interfaces.
Bootstrapped and regtested on power64-linux-gnu.
Review comments incorporated.
Thanks & Regards
Ajit
Nit: This seems to belong to "what changed in
On 9/18/23 13:10, Andrew Waterman wrote:
Vineet,
Your understanding of the ABI is correct; both int and unsigned int
arguments must already be sign-extended. The sext.w is semantically
unnecessary; the bltu could correctly reference a1 instead of a6.
Good luck eliminating it!
Thanks for the
Hi Jeff, Andrew
I've been looking into redundant sign extension and while there are
things to be improved in REE, there's something I wanted to confirm
before heading off into the weeds.
Consider the test below:
int foo(int unused, int n, unsigned y, unsigned delta){
int s = 0;
unsigned
On 8/29/23 08:40, Joern Rennecke wrote:
In the patch call we talked about sign extsnsion elimination, so I dug
up this patch set that I did a while ago. It is still lacking some
documentation and testing in a more recent base version;
I only adjusted the common.opt part context for the patch to
ture/stackalign/setjmp-3.c -O1 execution test
FAIL: gcc.dg/torture/stackalign/setjmp-3.c -O1 -fpic execution test
gcc/ChangeLog:
* config/riscv/zicond.md: Fix op2 pattern.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/zicond.md | 2 +-
1 file changed, 1 insertion(+), 1 deletio
.dg/torture/stackalign/setjmp-3.c -O1 -fpic execution test
gcc/ChangeLog:
* config/riscv/zicond.md: Fix op2 pattern.
Fixes: 1d5bc3285e8a ("[committed][RISC-V] Fix 20010221-1.c with zicond")
Signed-off-by: Vineet Gupta
---
changes since v1
- instead of discarding opt2 pattern,
On 9/1/23 10:40, Palmer Dabbelt wrote:
Just working through this in email, as there's a lot of
double-negatives and I managed to screw up my Linux PR this morning so
I may not be thinking that well...
The docs say "(if_then_else test true-value false-value)". So in this
case it's
On 9/1/23 06:13, Jeff Law wrote:
I could very well be mistaken, but define_insn is a pattern match and
opt2 has *ne* so the expression has to be in != form and thus needs
to work with that condition. No ?
My point was that
x = (a != 0) ? x : 0
is equivalent to
x = (a == 0) ? 0 : x
You
On 8/31/23 06:51, Jeff Law wrote:
On 8/30/23 15:57, Vineet Gupta wrote:
This was tripping up gcc.c-torture/execute/pr60003.c at -O1 since the
pattern semantics can't be expressed by zicond instructions.
This involves test code snippet:
if (a == 0)
return 0;
else
4,8(sp) lda5,8(sp)
czero.nez a0,a4,a5 czero.eqz a0,a5,a0
The issue only happens at -O1 as at higher optimization levels, the
whole conditional move gets optimized away.
gcc/ChangeLog:
* config/riscv/zicond.md: Remove incorrect op2 pattern.
Fixes: 1d5bc3285e8a ("[commi
o.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv.cc | 18 +-
gcc/testsuite/gcc.target/riscv/gcse-const.c| 13 +
.../riscv/rvv/vsetvl/vlmax_conflict-7.c| 1 -
.../riscv/rvv/vsetvl/vlmax_conflict-8.c| 1 -
4 files c
o.
Signed-off-by: Vineet Gupta
---
Changes since v1
- Simplified code under case CONST.
- Added some comments for handling of CONST_INT in 2 places.
---
gcc/config/riscv/riscv.cc | 18 +-
gcc/testsuite/gcc.target/riscv/gcse-const.c| 13 +
...
Hi Jivan,
On 8/24/23 08:45, Jivan Hakobyan via Gcc-patches wrote:
This patch fixes failing stack_save_restore_1/2 test cases.
After 6619b3d4c15c commit size of the frame was changed.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/stack_save_restore_1.c: Update frame size
*
On 8/23/23 13:04, Jeff Law wrote:
Thanks for your patience on this. I needed a bit of time to gather my
thoughts and review some code.
No worries at all.
index 8b7256108157..1802eef908fc 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -2464,14 +2464,9 @@
On 8/22/23 11:07, Palmer Dabbelt wrote:
We should probably put them in invoke.texi as well (and anything else
we're missing that's been added recently).
Looks like I'd pushed the patch already.
A whole bunch of them are missing, so guess that can happen seperately.
-Vineet
... otherwise user has no clue what -param to actually change
gcc/ChangeLog:
* config/riscv/riscv.opt: Add --param names
riscv-autovec-preference and riscv-autovec-lmul
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv.opt | 4 ++--
1 file changed, 2 insertions(+), 2
... otherwise user has no clue what -param to actually change
gcc/ChangeLog:
* config/riscv/riscv.opt: Add --param names
riscv-autovec-preference and riscv-autovec-lmul
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv.opt | 4 ++--
1 file changed, 2 insertions(+), 2
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
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
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.cgi?id
.
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
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
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 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
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
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/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
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 look.
FWIW
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
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 v3 vs
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
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 =
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
Date: Thu Jul 20 11:15:37 2023 -0700
RISC-V: optim const
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(+), 5 deletions(
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; }
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
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
* 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, mention
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
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/predicates.md
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])
|
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
lf-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 16:33, Vi
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
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 trying
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]))
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
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
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
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-init
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
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 bubbled up
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' file where the
E
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
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
---
gcc
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
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
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".
The full
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/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 relatively
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:
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
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
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
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
+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/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
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/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
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
/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/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
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
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 one up
+ 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
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
On 4/20/23 09:56, Jeff Law via Gcc-patches wrote:
On 1/17/23 15:59, Vineet Gupta wrote:
This could be useful for library writers who want to write code variants
for fast vs. slow unaligned accesses.
We distinguish explicit -mstrict-align (1) vs. slow_unaligned_access
cpu tune param (2
On 4/25/23 13:03, Jeff Law wrote:
On 4/25/23 11:25, Vineet Gupta wrote:
On 4/18/23 11:36, Jeff Law via Gcc-patches wrote:
On 4/18/23 08:36, Vineet Gupta wrote:
[partial addressing of PR/109279]
RISCV splitters have restrictions to not create pesudos due to a
combine
limitatation
On 4/18/23 11:36, Jeff Law via Gcc-patches wrote:
On 4/18/23 08:36, Vineet Gupta wrote:
[partial addressing of PR/109279]
RISCV splitters have restrictions to not create pesudos due to a combine
limitatation. And despite this being a split-during-combine limitation,
all split passes take
On 4/19/23 00:05, Richard Biener wrote:
On Tue, Apr 18, 2023 at 10:51 PM Vineet Gupta wrote:
when debugging expmed.[ch] for PR/108987 saw that some of the cost arrays have
less than ideal layout as follows:
x_shift*cost[0..63][speed][modes]
We would want speed to be first index since
Vineet Gupta wrote:
On 4/21/23 02:30, Richard Sandiford wrote:
No approval is needed when adding oneself to write-after-approval.
The fact that one's able to make the change is proof enough.
Thx Richard.
Noob question: I tried to commit/push but failed.
| $ git remote show upstream
| * remote
On 4/21/23 02:30, Richard Sandiford wrote:
No approval is needed when adding oneself to write-after-approval.
The fact that one's able to make the change is proof enough.
Thx Richard.
Noob question: I tried to commit/push but failed.
| $ git remote show upstream
| * remote upstream
|
ChangeLog:
* MAINTAINERS (Write After Approval): Add myself.
(Ref: <680c7bbe-5d6e-07cd-8468-247afc65e...@gmail.com>)
Signed-off-by: Vineet Gupta
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index cebf45d49e56..5f25617212a5
()): Access x_shift*_cost array directly.
Signed-off-by: Vineet Gupta
---
Changes since v1:
- Post a non stale version of patch
---
gcc/expmed.h | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/gcc/expmed.h b/gcc/expmed.h
index c747a0da1637
On 4/18/23 11:36, Jeff Law wrote:
On 4/18/23 08:36, Vineet Gupta wrote:
[partial addressing of PR/109279]
RISCV splitters have restrictions to not create pesudos due to a combine
limitatation. And despite this being a split-during-combine limitation,
all split passes take the hit due
()): Access x_shift*_cost array directly.
Signed-off-by: Vineet Gupta
---
gcc/expmed.h | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/gcc/expmed.h b/gcc/expmed.h
index c747a0da1637..d032beaef550 100644
--- a/gcc/expmed.h
+++ b/gcc/expmed.h
litter arg.
riscv_force_temporary() drop in_splitter arg.
* config/riscv/riscv-protos.h: riscv_move_integer() drop in_splitter
arg.
riscv_split_symbol() drop in_splitter arg.
Signed-off-by: Vineet Gupta
---
Changes since v1:
- Added customary Changlog
---
gcc/config/r
PR/109279 and was suggested by
Andrew Pinski.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv-protos.h | 4 +--
gcc/config/riscv/riscv.cc | 46 +
gcc/config/riscv/riscv.md | 8 +++---
3 files changed, 24 insertions(+), 34 deletions(-)
diff --git a/
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
.
* gcc.target/riscv/predef-align-4.c: New test.
* gcc.target/riscv/predef-align-5.c: New test.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv-c.cc | 11 +++
gcc/config/riscv/riscv.cc | 9 +
gcc/config/riscv/riscv.h
On 11/13/22 15:05, Christoph Muellner wrote:
+static bool
+riscv_overlap_op_by_pieces (void)
+{
+ return tune_param->overlap_op_by_pieces;
Does this not need to be gated on unaligned access enabled as well.
-Vineet
On 10/13/22 15:39, Jeff Law via Gcc-patches wrote:
On 10/11/22 17:31, Vineet Gupta wrote:
I expect that the pressure for a proper fix upstream (instead of a
backward compatible compromise) will increase over time (once people
start building big iron based on RISC-V and start hunting
On 10/11/22 13:46, Christoph Müllner wrote:
On Tue, Oct 11, 2022 at 9:31 PM Palmer Dabbelt wrote:
On Tue, 11 Oct 2022 12:06:27 PDT (-0700), Vineet Gupta wrote:
> Hi Christoph, Kito,
>
> On 5/5/21 12:36, Christoph Muellner via Gcc-patches wrote:
>> This
Hi Christoph, Kito,
On 5/5/21 12:36, Christoph Muellner via Gcc-patches wrote:
This series provides a cleanup of the current atomics implementation
of RISC-V:
* PR100265: Use proper fences for atomic load/store
* PR100266: Provide programmatic implementation of CAS
As both are very related, I
On 10/4/22 19:24, Kito Cheng wrote:
Committed, and added ChangeLog, remember to add that next time:)
Oops sorry, I will.
Thx,
-Vineet
On 9/2/22 14:05, Vineet Gupta wrote:
Came across this deprecated symbol when looking around for
-mexplicit-relocs handling in code
Signed-off-by: Vineet Gupta
No rush but looks like this got lost in the bigger thread about
LOAD_ADDRESS_MACRO.
Thx,
-Vineet
---
gcc/config/riscv/riscv
The current macro has several && and || making it really hard to understand
the first time.
Signed-off-by: Vineet Gupta
---
Since we are on this topic, perhaps get this simplification too.
But I'm not sure if the current checking of local symbol can be simplified
a bit. Isn't the fi
101 - 200 of 258 matches
Mail list logo
