Hi, Richi. Since SELECT_VL only apply on single-rgroup (ncopies == 1 && vec_num
== 1)
Should I make SELECT_VL stuff out side the loop?
for (i = 0; i < vec_num; i++)
for (j = 0; j < ncopies; j++)
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-06-07 15:41
To: Ju-Zhe Zhong
I see what you mean now, so I've made adjustment in order for testcase to work
on assembly. Following is the updated patch.
Regards,
Jovan
>From 2744357b5232c61bf1f780c4915d47b19d71f993 Mon Sep 17 00:00:00 2001
From: Jovan Dmitrovic
Date: Fri, 19 May 2023 12:36:55 +0200
Subject: [PATCH] mips:
Hello All:
This patch provide functionality to improve ree pass for rs6000 target.
Eliminated sign_extend/zero_extend/AND with varying constants.
Bootstrapped and regtested on powerpc64-linux-gnu.
Thanks & Regards
Ajit
ree: Improve ree pass for rs6000 target
For rs6000 target we see redundant
I saw this while working on something else:
pex_unix_cleanup signature doesn't always match the
body of the function in terms of ATTRIBUTE_UNUSED.
If the conditional code in the body is compiled, then
ATTRIBUTE_UNUSED isn't correct.
This change makes it always match, thereby making it
a bit
On 5/26/23 18:17, Martin Jambor wrote:
Hello,
On Mon, May 22 2023, Aldy Hernandez wrote:
I've adjusted the patch with some minor cleanups that came up when I
implemented the rest of the IPA revamp.
Rested. OK?
On Wed, May 17, 2023 at 4:31 PM Aldy Hernandez wrote:
This converts the
Seems there are some indent format problems in the patch, could you fix them :)
```
patch:509: indent with spaces.
x_save_size = riscv_stack_align (num_multi_push * UNITS_PER_WORD);
error: patch failed: gcc/config/riscv/riscv.cc:5652
error: gcc/config/riscv/riscv.cc: patch does not
On 5/29/23 16:51, Martin Jambor wrote:
Hi,
On Mon, May 22 2023, Aldy Hernandez via Gcc-patches wrote:
Implement hashing for ipa_vr. When all is said and done, all these
patches incurr a 7.64% slowdown for ipa-cp, with is entirely covered by
the similar 7% increase in this area last week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110145
--- Comment #6 from Jakub Jelinek ---
So perhaps just wrap that single test with #if FLT_EVAL_METHOD == 0 ||
FLT_EVAL_METHOD == 1 (to make sure double constants are evaluated to double
precision)?
Or use 0x1.7a2ecc414a03fp+418 instead of 1e126?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110145
--- Comment #5 from Jakub Jelinek ---
Now, putting a breakpoint on round_for_format, seems the constant is actually
0xb.d176620a501fbffb650e5a93bc3d89854bea8f289011b2bp+415 or so before rounding
aka
Hi,
on 2023/6/7 03:54, Carl Love wrote:
> On Mon, 2023-06-05 at 16:45 +0800, Kewen.Lin wrote:
>> Hi Carl,
>>
>> on 2023/5/2 23:52, Carl Love via Gcc-patches wrote:
>>> GCC maintainers:
>>>
>>> The following patch adds three buitins for inserting and extracting
>>> the
>>> exponent and significand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110153
Bug ID: 110153
Summary: [modules] Static module mapper format cannot handle
header unit paths with spaces
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110145
Jakub Jelinek changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment
Hi!
On 2023-06-07T09:12:31+0100, Jonathan Wakely wrote:
> On Wed, 7 Jun 2023 at 08:13, Thomas Schwinge wrote:
>> On 2023-06-06T20:31:21+0100, Jonathan Wakely wrote:
>> > On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge
>> > wrote:
>> >> This issue comes up in context of me working on C++ support
Thanks Juzhe for reviewing. I see, this way may have even smaller code change
which treats the zvfhmin as minimal base sub extension.
I will have a try for PATCH V6.
Pan
From: juzhe.zh...@rivai.ai
Sent: Wednesday, June 7, 2023 4:27 PM
To: Li, Pan2 ; gcc-patches
Cc: Robin Dapp ; jeffreyalaw ;
Thanks Jakub!
I do need those includes and sorry I broke your bootstrap it didn't show
up on my aarch64-unknown-linux-gnu bootstrap, I'm guessing the rules
there were just run in a different order. Glad you were able to fix it :)
On 06/06/2023 22:28, Jakub Jelinek wrote:
Hi!
internal-fn.h
This patch improves bit-extractions on AVR.
Andrew added some patches so that more bit extractions are
recognized in the middle-end and rtl optimizers.
The patch adds pattern for "extzv" and replaces the
deprecated "extzv".
There are still situations where expensive shifts are passed
down to
Ping #2 for:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618976.html
https://gcc.gnu.org/pipermail/gcc-patches/attachments/20230519/9536bf8c/attachment-0001.bin
Ping #1:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620098.html
Johann
Am 19.05.23 um 10:49 schrieb Georg-Johann
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110152
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
In this patch, you add TARGET_ZVFH into VF iterator which is not correct.
When TARGET_ZVFH is true, TARGET_ZVFHMIN is always true.
For vfadd, it is true we should enable "vfadd" for TARGET_ZVFH
For vle16, we should enable for TARGET_ZVFHMIN.
This patch will disable both "vle16" and "vfadd" for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110152
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |14.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110142
--- Comment #2 from Tamar Christina ---
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110152
Bug ID: 110152
Summary: [14 Regression] ICE on 3dnow-1.c since r14-1166
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110142
--- Comment #1 from avieira at gcc dot gnu.org ---
Found the issue to be with passing a subtype to vect_recog_widen_op_pattern in
vect_recog_widen_{plus,minus}_pattern where we didn't before. Removing those
and letting it default to a NULL
Hi,
This patch tries to optimize "(X - N * M) / N" to "X / N - M".
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 cross zero and does not wrap/overflow/underflow.
Compare with previous version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110038
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110122
--- Comment #5 from waffl3x ---
(In reply to Patrick Palka from comment #4)
>
> Yes, it seems the original testcase is exhibiting two bugs (one of which a
> GCC 13 regression), whereas the second testcase exhibits one
> (non-regression) bug.
>
Several tests are timing out when targeting x86-*-vxworks with qemu.
Bump their timeout factor.
for gcc/testsuite/ChangeLog
* gcc.dg/vect/tsvc/vect-tsvc-s116.c: Bump timeout factor.
* gcc.dg/vect/tsvc/vect-tsvc-s241.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s254.c:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781
Bug 88781 depends on bug 110151, which changed state.
Bug 110151 Summary: warning: 'strncpy' output truncated copying 10 bytes from a
string of length 26 [-Wstringop-truncation]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110151
On Wed, 7 Jun 2023 at 08:13, Thomas Schwinge wrote:
> Hi!
>
> On 2023-06-06T20:31:21+0100, Jonathan Wakely wrote:
> > On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge
> > wrote:
> >> This issue comes up in context of me working on C++ support for GCN and
> >> nvptx target. Those targets shall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107473
Xionghu Luo (luoxhu at gcc dot gnu.org) changed:
What|Removed |Added
CC||yinyuefengyi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110151
Xionghu Luo (luoxhu at gcc dot gnu.org) changed:
What|Removed |Added
Resolution|--- |DUPLICATE
I am not sure for load/stores of FP16 vector should be gated by ZVFHMIN or ZVFH?
Since IMHO, load/stores of FP16 is no different from load/stores of INT16?
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-06-07 16:06
To: gcc-patches
CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang
Minor change in PATCH V5, please help to turn to V5 as below, sorry for
inconvenient.
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620890.html
Pan
From: Li, Pan2
Sent: Wednesday, June 7, 2023 2:57 PM
To: 'juzhe.zh...@rivai.ai' ; 'gcc-patches'
Cc: 'Kito.cheng' ; Wang, Yanzhang
On Wed, 7 Jun 2023 at 05:43, François Dumont wrote:
>
> On 06/06/2023 17:59, Jonathan Wakely via Libstdc++ wrote:
> > Tested x86_64-linux and powerpc64le-linux. Pushed to trunk.
> >
> > -- >8 --
> >
> > Add the recently added CXXABI_1.3.15 version. Also remove two "frozen"
> > versions from the
From: Pan Li
This patch would like to refactor the requirement of both the ZVFH
and ZVFHMIN. The related define_insn and iterator will take the
requirement based on the ZVFHMIN and ZVFH.
Please note the ZVFH will cover the ZVFHMIN instructions. This patch
add one test for this.
Signed-off-by:
Hi, Richi.
Thanks for review.
>> At least for VMAT_GATHER_SCATTER you wouldn't execute this function
>> but get into
>>This function belongs to tree-vect-data-refs.cc alongside the
>>other vect_create_data_ref_* functions.
I want to support data reference pointer adjusted by outcome of SELECT_VL.
在 2023/6/7 下午3:37, WANG Xuerui 写道:
On 2023/6/7 11:36, Lulu Cheng wrote:
在 2023/6/7 上午11:26, WANG Xuerui 写道:
Hi,
On 2023/6/7 10:31, Lulu Cheng wrote:
If the $ra register is modified during the jump to the jump table,
the hardware
branch prediction function will be broken, resulting in a
During the regression testing of the LoongArch architecture GCC, it was
found that the tests in the pr90883.C file failed. The problem was modulated and
found that the error was caused by setting the macro LARCH_CALL_RATIO to a too
large value. Combined with the actual LoongArch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71414
--- Comment #15 from rguenther at suse dot de ---
On Wed, 7 Jun 2023, crazylht at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71414
>
> --- Comment #14 from Hongtao.liu ---
> (In reply to Richard Biener from comment
On Mon, 5 Jun 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> Co-authored-by: Richard Sandiford
>
> This patch address comments from Richard and rebase to trunk.
>
> This patch is adding SELECT_VL middle-end support
> allow target have target dependent optimization in case of
>
On 2023/6/7 11:36, Lulu Cheng wrote:
在 2023/6/7 上午11:26, WANG Xuerui 写道:
Hi,
On 2023/6/7 10:31, Lulu Cheng wrote:
If the $ra register is modified during the jump to the jump table,
the hardware
branch prediction function will be broken, resulting in a significant
increase
in the branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71414
--- Comment #14 from Hongtao.liu ---
(In reply to Richard Biener from comment #13)
> The target now has the ability to tell the vectorizer to choose a larger VF
> based on the cost info it got for the default VF, so the x86 backend could
> make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104271
Richard Biener changed:
What|Removed |Added
Target Milestone|12.4|12.3
Hi Tobias,
We are also seeing this failure on arm-linux-gnueabihf.
It seems the problem is different order of variables in output:
- c a e d b
versus expected
- c a e b d
This is tree-dump output on arm-linux-gnueabihf:
#pragma omp target update to(c [len: 4]) to(present:a [len: 4000])
Hi!
On 2023-06-06T20:31:21+0100, Jonathan Wakely wrote:
> On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge
> wrote:
>> This issue comes up in context of me working on C++ support for GCN and
>> nvptx target. Those targets shall default to '-fno-exceptions' -- or,
>> "in other words",
On Tue, Jun 06, 2023 at 05:17:05PM -0700, Andrew Pinski via Gcc-patches wrote:
> While working on `bool0 ? bool1 : bool2` I noticed that
> zero_one_valued_p does not match on the constant zero
> as in that case tree_nonzero_bits will return 0 and
> that is different from 1.
>
> OK? Bootstrapped
On Wed, Jun 7, 2023 at 8:32 AM Uros Bizjak wrote:
>
> On Wed, Jun 7, 2023 at 1:05 AM Roger Sayle wrote:
> >
> >
> > This patch addresses the last remaining issue with PR target/31985, that
> > GCC could make better use of memory addressing modes when implementing
> > double word addition. This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 104271, which changed state.
Bug 104271 Summary: [12 Regression] 538.imagick_r run-time at -Ofast
-march=native regressed by 26% on Intel Cascade Lake server CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104271
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104271
Sam James changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Update the PATCH V4 as below, sorry for missed the v4 prefix in subject.
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620879.html
Pan
From: Li, Pan2
Sent: Wednesday, June 7, 2023 2:21 PM
To: juzhe.zh...@rivai.ai; gcc-patches
Cc: Kito.cheng ; Wang, Yanzhang
Subject: RE: [PATCH v3]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71414
Richard Biener changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment
From: Pan Li
This patch would like to refactor the requirement of both the ZVFH
and ZVFHMIN. The related define_insn and iterator will take the
requirement based on the ZVFHMIN and ZVFH.
Please note the ZVFH will cover the ZVFHMIN instructions. This patch
add one test for this.
Signed-off-by:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110062
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
On Wed, Jun 7, 2023 at 1:05 AM Roger Sayle wrote:
>
>
> This patch addresses the last remaining issue with PR target/31985, that
> GCC could make better use of memory addressing modes when implementing
> double word addition. This is achieved by adding a define_insn_and_split
> that combines an
PR106907 has few warnings spotted from cppcheck. Inorder to clarify the
order of precedence between operators added parentheses to explicitly
group operations based on desired order of evaluation.
2023-06-07 Jeevitha Palanisamy
gcc/
PR target/106907
* config/gcn/gcn.cc
Thanks JuZhe, make sense, will update the V4 for this change.
Pan
From: juzhe.zh...@rivai.ai
Sent: Wednesday, June 7, 2023 12:21 PM
To: Li, Pan2 ; gcc-patches
Cc: Kito.cheng ; Li, Pan2 ; Wang,
Yanzhang
Subject: Re: [PATCH v3] RISC-V: Refactor requirement of ZVFH and ZVFHMIN.
HI,
+ (VNx1SF
On Tue, Jun 6, 2023 at 11:00 PM Roger Sayle wrote:
>
>
> Hi Uros,
> Might you willing to approve the patch without the *x86_clc pieces?
> These can be submitted later, when they are actually used. For now,
> we're arguing about the performance of a pattern that's not yet
> generated on an
Hi David,
David Edelsohn writes:
>
> Hi, Jiufu
> * config/rs6000/rs6000.cc (can_be_rotated_to_possitive_li): New
> function.
> (can_be_rotated_to_negative_li): New function.
> (can_be_built_by_li_and_rotldi): New function.
> (rs6000_emit_set_long_const): Call
201 - 258 of 258 matches
Mail list logo
