On Tue, 16 May 2023 17:16:11 PDT (-0700), Vineet Gupta wrote:
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
The problem here is that VRP cannot figure out isize could not be 0
due to using integer_zerop. This patch removes the use of integer_zerop
and instead checks for 0 directly after converting the tree to
an unsigned HOST_WIDE_INT. This allows VRP to figure out isize is not 0
and `isize - 1` will alw
+ 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 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?
Patrick's github CI patch seems to be a great
From: Juzhe-Zhong
Hi, since fixed-point with modeling rounding mode intrinsics are coming:
https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/222
I am adding vxrm rounding mode enum to user first before the API intrinsic.
This patch is simple && obvious.
Ok for trunk ?
gcc/ChangeLog:
Hi, Palmer.
I saw your patch showed there are a lot of run time fail (execution fail) of
C++.
bug-*.C
These tests are RVV api intrinsics tests coming from Kito's that I have already
fixed all of them.
I just double checked again they all passed.
I think it may be your regression environment does
On 5/16/23 19:29, Palmer Dabbelt wrote:
I think the most pressing need is bleeding edge gcc regression tracking.
@Jeff is anything setup on sourceware and/or usable ? I thought they
do have existing bots for some arches to spin up build / run - perhaps
runs are native and not qemu.
IIRC
On Tue, May 16, 2023 at 6:58 PM juzhe.zh...@rivai.ai
wrote:
>
> Hi, Palmer.
> I saw your patch showed there are a lot of run time fail (execution fail) of
> C++.
> bug-*.C
>
> These tests are RVV api intrinsics tests coming from Kito's that I have
> already fixed all of them.
> I just double che
On Tue, 16 May 2023 19:00:12 PDT (-0700), Jeff Law wrote:
On 5/16/23 19:29, Palmer Dabbelt wrote:
I think the most pressing need is bleeding edge gcc regression tracking.
@Jeff is anything setup on sourceware and/or usable ? I thought they
do have existing bots for some arches to spin up
Oh, I see. Kito has add /* { dg-do run { target { riscv_vector } } } */
But not all RVV tests has use this and I not sure whether it can work.
I think Kito can answer it.
If yes, I think we should add all of them.
Thanks.
juzhe.zh...@rivai.ai
From: Andrew Pinski
Date: 2023-05-17 10:02
To: juzh
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?
P
On 5/16/23 20:08, Vineet Gupta wrote:
I think the most pressing need is bleeding edge gcc regression tracking.
@Jeff is anything setup on sourceware and/or usable ? I thought they
do have existing bots for some arches to spin up build / run - perhaps
runs are native and not qemu.
IIRC J
On Tue, 16 May 2023 19:07:01 PDT (-0700), juzhe.zh...@rivai.ai wrote:
Oh, I see. Kito has add /* { dg-do run { target { riscv_vector } } } */
But not all RVV tests has use this and I not sure whether it can work.
I think Kito can answer it.
If yes, I think we should add all of them.
Unless I'm
Hi,
On 2023-05-15 14:53, Kewen.Lin wrote:
Hi Jeff,
on 2022/12/12 09:38, Jiufu Guo wrote:
Hi,
For constant C:
If '(c & 0xULL) == 0x' or say:
32(1) || 1(0) || 15(x) || 16(0), we could use "lis; xoris" to build.
Here N(M) means N continuous bit M, x for M means i
Currently we are highly rely on simulator can setup correctly by ELF
attribute or -march setting, but seems not true for everyone, for
longer term we need something like
check_effective_target_aarch64_sve_hw, but as Palmer point out, we
might need...bunch of that for different extensions
On We
Palmer:
For short-term, this should help your internal test:
https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1233
On Wed, May 17, 2023 at 10:20 AM Kito Cheng wrote:
>
> Currently we are highly rely on simulator can setup correctly by ELF
> attribute or -march setting, but seems not true
On 5/16/23 20:05, Palmer Dabbelt wrote:
On Tue, 16 May 2023 19:00:12 PDT (-0700), Jeff Law wrote:
On 5/16/23 19:29, Palmer Dabbelt wrote:
I think the most pressing need is bleeding edge gcc regression
tracking.
@Jeff is anything setup on sourceware and/or usable ? I thought they
do h
On Tue, 16 May 2023 19:32:21 PDT (-0700), jeffreya...@gmail.com wrote:
On 5/16/23 20:05, Palmer Dabbelt wrote:
On Tue, 16 May 2023 19:00:12 PDT (-0700), Jeff Law wrote:
On 5/16/23 19:29, Palmer Dabbelt wrote:
I think the most pressing need is bleeding edge gcc regression
tracking.
@Je
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 Tue, 16 May 2023 19:46:28 PDT (-0700), Vineet Gupta wrote:
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
regula
On 5/16/23 19:47, Palmer Dabbelt wrote:
On Tue, 16 May 2023 19:46:28 PDT (-0700), Vineet Gupta wrote:
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 blee
On Tue, 16 May 2023 19:51:48 PDT (-0700), Patrick O'Neill wrote:
On 5/16/23 19:47, Palmer Dabbelt wrote:
On Tue, 16 May 2023 19:46:28 PDT (-0700), Vineet Gupta wrote:
On 5/16/23 19:21, Kito Cheng wrote:
Palmer:
For short-term, this should help your internal test:
https://github.com/riscv-col
I would like to defer this until the PR has updated.
On Wed, May 17, 2023 at 9:52 AM wrote:
>
> From: Juzhe-Zhong
>
> Hi, since fixed-point with modeling rounding mode intrinsics are coming:
> https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/222
>
> I am adding vxrm rounding mode enum to
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 Tue, 16 May 2023 20:08:26 PDT (-0700), Vineet Gupta wrote:
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
Even easier, I think I can get away with
> +
> +/* Get the mask for merge approach.
> +
> + Consider such following case:
> + {a, b, a, b, a, b, a, b, a, b, a, b, a, b, a, b}
> + To merge "a", the mask should be 1010
> + To merge "b", the mask should be 0101
> +*/
> +rtx
> +rvv_builder::get_merge_mask_bitfield (u
> diff --git a/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run
> b/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run
> index 94d6ec5..efc3a80 100755
> --- a/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run
> +++ b/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run
> @@ -12,4 +12,4 @@ done
>
>> Does it means we assume inner_int_mode is DImode? (because sizeof (uint64_t))
>> or it should be something like `for (unsigned int i = 0; i <
>> (GET_MODE_SIZE(inner_int_mode ()) * 8 / npatterns ()); i++)` ?
No, sizeof (uint64_t) means uint64_t mask = 0;
>> Do you mind give more comment about t
On Wed, May 17, 2023 at 11:36 AM juzhe.zh...@rivai.ai
wrote:
>
> >> Does it means we assume inner_int_mode is DImode? (because sizeof
> >> (uint64_t))
> >> or it should be something like `for (unsigned int i = 0; i <
> >> (GET_MODE_SIZE(inner_int_mode ()) * 8 / npatterns ()); i++)` ?
> No, sizeof
On 5/16/23 21:33, Kito Cheng via Gcc-patches wrote:
diff --git a/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run
b/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run
index 94d6ec5..efc3a80 100755
--- a/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run
+++ b/scripts/wrapper/qemu/riscv64-un
On 5/16/23 20:39, Palmer Dabbelt wrote:
By "chroot environment" you mean something like a
debootstrap-into-chroot with qemu-user/binfmt-misc? I don't have that
setup right now, but it wouldn't be a big lift.
Essentially, yes. I actually have a home built ones for the various
targets. T
On 5/10/23 09:50, Jivan Hakobyan via Gcc-patches wrote:
Subject:
RISC-V: Remove masking third operand of rotate instructions
From:
Jivan Hakobyan via Gcc-patches
Date:
5/10/23, 09:50
To:
gcc-patches@gcc.gnu.org
Rotate instructions do not need to mask the third operand.
For example RV64 th
From: Juzhe-Zhong
According to new comming fixed-point API:
https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/222
Introduce vxrm argument:
- vint32m1_t __riscv_vsadd_vv_i32m1 (vint32m1_t op1, vint32m1_t op2, size_t vl);
+ vint32m1_t __riscv_vsadd_vv_i32m1 (vint32m1_t op1, vint32m1_t op2, s
Hi,
When working on a cost tweaking patch, I found that a newly
added test case has different dumpings with stage-1 and
bootstrapped gcc. By looking into it, the apparent reason
is vect_analyze_loop_2 doesn't get slp_done_for_suggested_uf
set expectedly, the following retrying will use the garbag
Hi,
This patch is to refactor the handlings for the case (index
== count) in a loop of vect_transform_slp_perm_load_1, in
order to prepare a subsequent adjustment on *nperm. This
patch doesn't have any functional changes.
Bootstrapped and regtested on x86_64-redhat-linux,
aarch64-linux-gnu and p
Hi,
This patch tries to optimize "(X - N * M) / N + M" to "X / N".
As per the discussions in PR108757, we know this transformation is valid
only under some conditions.
For C code, "/" towards zero (trunc_div), and "X - N * M"
maybe wrap/overflow/underflow. So, it is valid that "X - N * M" does
not
Hi,
Following Richi's suggestion in [1], I'm working on deferring
cost evaluation next to the transformation, this patch is
to enhance function vect_transform_slp_perm_load_1 which
could under-cost for vector permutation, since the costing
doesn't try to consider nvectors_per_build, it's inconsist
On Tue, May 16, 2023 at 9:11 AM Robin Dapp via Gcc-patches
wrote:
>
> > This patch would like to align the stdint.h to the stdint-gcc.h for all
> > the RVV test files. Aka:
> >
> > stdint.h => stdint-gcc.h
>
> Looks good. Jeff already pre-approved so you can go ahead and install
> this on the tru
Hi,
I'd like to gentle ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614818.html
BR,
Kewen
on 2023/3/29 15:18, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> By addressing Alexander's comments, against v1 this
> patch v2 mainly:
>
> - Rename no_real_insns_p to no_real_no
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614228.html
BR,
Kewen
on 2023/3/20 14:33, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> One of my workmates found there is a warning like:
>
> libgcc/config/rs6000/morestack.S:402: Warning: ignoring
> incorrect sect
> Huh, including stdint-gcc.h looks completely wrong. What's the issue you are
> trying to solve?
The way I understood it is that that's a temporary workaround until
all multilib et al. (+testsuite) configurations are in place but I
haven't checked the details myself. Eventually this should be d
Hi,
Gentle ping this series:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607146.html
BR,
Kewen
>
> on 2022/11/24 17:15, Kewen Lin wrote:
>> Hi,
>>
>> Following Segher's suggestion, this patch series is to rework
>> function rs6000_emit_vector_compare for vector float and int
>> in
On Wed, May 17, 2023 at 2:54 AM Andrew Pinski via Gcc-patches
wrote:
>
> The problem here is that VRP cannot figure out isize could not be 0
> due to using integer_zerop. This patch removes the use of integer_zerop
> and instead checks for 0 directly after converting the tree to
> an unsigned HOST
On Wed, May 17, 2023 at 8:06 AM Kewen.Lin wrote:
>
> Hi,
>
> When working on a cost tweaking patch, I found that a newly
> added test case has different dumpings with stage-1 and
> bootstrapped gcc. By looking into it, the apparent reason
> is vect_analyze_loop_2 doesn't get slp_done_for_suggeste
On Wed, May 17, 2023 at 8:09 AM Kewen.Lin wrote:
>
> Hi,
>
> This patch is to refactor the handlings for the case (index
> == count) in a loop of vect_transform_slp_perm_load_1, in
> order to prepare a subsequent adjustment on *nperm. This
> patch doesn't have any functional changes.
The diff is
On Mon, May 15, 2023 at 3:56 PM Jason Merrill wrote:
>
> On 5/15/23 03:32, Richard Biener wrote:
> > On Fri, May 12, 2023 at 10:54 PM Jason Merrill via Gcc-patches
> > wrote:
> >>
> >> In the context of the recent discussion, it occurred to me that this
> >> semantic
> >> would be useful, but cu
Gentle ping...
Jiufu Guo via Gcc-patches writes:
> Hi
>
> I would like to ping this patch for stage1:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612168.html
>
> BR,
> Jeff (Jiufu)
>
> Jiufu Guo writes:
>
>> Hi,
>>
>> Compare with previous version:
>> https://gcc.gnu.org/pipermail
Gentle ping...
Jiufu Guo via Gcc-patches writes:
> Hi,
>
> I would ping this patch for stage1:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609504.html
>
> BR,
> Jeff (Jiufu)
>
> Jiufu Guo via Gcc-patches writes:
>
>> Hi,
>>
>> Gently Ping:
>> https://gcc.gnu.org/pipermail/gcc-pat
Gentle ping...
Jiufu Guo via Gcc-patches writes:
> Hi,
>
> I'm thinking that we may enable this patch for stage1, so ping it.
> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603530.html
>
> BR,
> Jeff (Jiufu)
>
> Jiufu Guo writes:
>
>> Hi,
>>
>> There is a functionality as const_anch
RISC-V glibc will require corresponding muilti-lib has built there,
otherwise will report something like:
/usr/include/gnu/stubs.h:11:11: fatal error: gnu/stubs-ilp32d.h: No
such file or directory
But actually we only require those fixed length types to compile and
scan assembly or dump,
So we
r14-172-g0368d169492017 replaces GENERAL_REGS with NO_REGS in cost
calculation when the preferred register class are not known yet.
It regressed powerpc PR109610 and PR109858, it looks too aggressive to use
NO_REGS when mode can be allocated with GENERAL_REGS.
The patch takes a step back, still use
101 - 151 of 151 matches
Mail list logo
