On Sat, 13 May 2023, Andrew Pinski via Gcc-patches wrote:
> +/* signbit(x) != 0 ? -x : x -> abs(x)
> + signbit(x) == 0 ? -x : x -> -abs(x) */
> +(for sign (SIGNBIT)
Surprised to see a dummy iterator here. Was this meant to include
float and long double versions of the builtin too (SIGNBITF an
On Sun, 14 May 2023, Alexander Monakov wrote:
> On Sat, 13 May 2023, Andrew Pinski via Gcc-patches wrote:
>
> > +/* signbit(x) != 0 ? -x : x -> abs(x)
> > + signbit(x) == 0 ? -x : x -> -abs(x) */
> > +(for sign (SIGNBIT)
>
> Surprised to see a dummy iterator here. Was this meant to include
>
H Bernhard,
> On 14 May 2023, at 00:23, Bernhard Reutner-Fischer via Gcc-patches
> wrote:
>
> From: Bernhard Reutner-Fischer
>
> gcc/objc/ChangeLog:
>
> * objc-act.cc (objc_volatilize_decl): Use _P() defines from tree.h.
> (objc_is_global_reference_p): Ditto.
> (objc_genera
From: Pan Li
This patch refactor the pattern A or B or C or D, to the switch case for
easy add/remove new types, as well as human reading friendly.
Before this patch:
return A || B || C || D;
After this patch:
switch (type)
{
case A:
case B:
case C:
case D:
return true;
Hi Bernhard
> On 14 May 2023, at 00:23, Bernhard Reutner-Fischer via Gcc-patches
> wrote:
>
> From: Bernhard Reutner-Fischer
>
> gcc/ChangeLog:
>
> * config/darwin-c.cc (darwin_pragma_unused): Ditto.
> * config/darwin.cc (is_objc_metadata): Ditto.
> * config/rs6000/darwin
OK, thanks :)
On Sun, May 14, 2023 at 4:22 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch refactor the pattern A or B or C or D, to the switch case for
> easy add/remove new types, as well as human reading friendly.
>
> Before this patch:
> return A || B || C || D;
>
> After th
Committed, thank you kito!
Pan
-Original Message-
From: Kito Cheng
Sent: Sunday, May 14, 2023 4:45 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Wang,
Yanzhang
Subject: Re: [PATCH] RISC-V: Refactor the or pattern to switch cases
OK, thanks
Le 10/05/2023 à 18:47, Bernhard Reutner-Fischer via Fortran a écrit :
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
PR fortran/78798
* array.cc (compare_bounds): Use narrower return type.
(gfc_compare_array_spec): Likewise.
(is_constant_element): Likewis
On 14.05.23 14:27, Mikael Morin wrote:
(...)
@@ -2098,7 +2098,7 @@ ref_same_as_full_array (gfc_ref *full_ref,
gfc_ref *ref)
there is some kind of overlap.
0 : array references are identical or not overlapping. */
-int
+bool
gfc_dep_resolver (gfc_ref *lref, gfc_ref *rref, gfc
Le 14/05/2023 à 01:23, Bernhard Reutner-Fischer via Gcc-patches a écrit :
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
* trans-array.cc (is_pointer_array): Use _P() defines from tree.h.
(gfc_conv_scalarized_array_ref): Ditto.
(gfc_conv_array_ref): Ditto.
On Sun, May 14, 2023 at 12:44 AM Alexander Monakov via Gcc-patches
wrote:
>
>
> On Sun, 14 May 2023, Alexander Monakov wrote:
>
> > On Sat, 13 May 2023, Andrew Pinski via Gcc-patches wrote:
> >
> > > +/* signbit(x) != 0 ? -x : x -> abs(x)
> > > + signbit(x) == 0 ? -x : x -> -abs(x) */
> > > +(fo
On Sun, 14 May 2023, Andrew Pinski wrote:
> It is NOT a dummy iterator. SIGNBIT is a operator list that expands to
> "BUILT_IN_SIGNBITF BUILT_IN_SIGNBIT BUILT_IN_SIGNBITL IFN_SIGNBIT".
Ah, it's in cfn-operators.pd in the build tree, not the source tree.
> > On the other hand, the following cl
On Sun, 14 May 2023 15:04:15 +0200
Thomas Koenig wrote:
> On 14.05.23 14:27, Mikael Morin wrote:
> >
> > (...)
> >> @@ -2098,7 +2098,7 @@ ref_same_as_full_array (gfc_ref *full_ref,
> >> gfc_ref *ref)
> >> there is some kind of overlap.
> >> 0 : array references are identical o
Rebased the patch to GCC 14 trunk. Bootstrapped and regression tested
again on x86_64-pc-linux-gnu, only difference is the new test failing
without the patch.
On Jul 13 2022, at 2:54 pm, Michal Jankovic
wrote:
> Hi Iain,
>
> thanks for the info. I have some follow-up questions.
>
> On Jul 12
Hi Alex,
thanks for working on this.
I’ve applied this patch and evaluated on a few Darwin versions (which is the
target currently most affected, I believe):
> On 9 May 2023, at 13:07, Alex Coplan wrote:
> This patch implements clang's __has_feature and __has_extension in GCC.
Thanks, this bl
Hi Michal,
> On 14 May 2023, at 16:36, Michal Jankovič wrote:
>
> Rebased the patch to GCC 14 trunk. Bootstrapped and regression tested
> again on x86_64-pc-linux-gnu, only difference is the new test failing
> without the patch.
(as previously noted, I am much in favour of this optimisation)
D
Dear Thomas Neumann,
I am contacting you as the author of the commit with commit hash
6e80a1d164d1f996ad08a512c25a7c2ca893 [1] in the GCC repository. In
this commit, you refactored the __register_frame/__deregister_frame
implementation in GCC. The commit is part of the GCC 13 release.
While up
Hi Iain,
I do not currently have metrics for this, but I can look into generating
them, however I currently do not know of any large open-source projects
using coroutines that I could use for this; I was thinking about using
cppcoro unit tests, but they mostly contain very simple coroutines. I
hav
Le 14/05/2023 à 17:24, Bernhard Reutner-Fischer a écrit :
On Sun, 14 May 2023 15:04:15 +0200
Thomas Koenig wrote:
On 14.05.23 14:27, Mikael Morin wrote:
(...)
@@ -2098,7 +2098,7 @@ ref_same_as_full_array (gfc_ref *full_ref,
gfc_ref *ref)
there is some kind of overlap.
0 :
Hi Michal,
> On 14 May 2023, at 17:31, Michal Jankovič via Gcc-patches
> wrote:
> I do not currently have metrics for this, but I can look into generating
> them,
To be clear, this is not in any way a precondition for patch acceptance
but I am curious as to some idea of the improvements seen.
Dear Sören,
we ran into a regression introduced by these changes. The regression
manifests itself in a failing assertion in __deregister_frame_info_bases.
The assertion failure was observed while using Chromium's `flatc` build
system tool. The failing assertion is:
unwind-dw2-fde.c:281
On Sun May 14, 2023 at 8:59 PM CEST, Thomas Neumann wrote:
> Dear Sören,
>
> > we ran into a regression introduced by these changes. The regression
> > manifests itself in a failing assertion in __deregister_frame_info_bases.
> > The assertion failure was observed while using Chromium's `flatc` bui
Revert my previous change that faked handling of V4HI and V2SImodes
in ix86_widen_mult_cost and rather return arbitrary high value
for unsupported modes. This should prevent cost estimator from
selecting non-existent vector widen multiply operation.
gcc/ChangeLog:
PR target/109807
* confi
Dear all,
Fortran allows functions in variable definition contexts when the
result variable is a pointer. We already handle this for the
non-CLASS case (in 11+), but the logic that checks the pointer
attribute was looking in the wrong place for the CLASS case.
Once found, the fix is simple and o
On Sun, May 14, 2023 at 10:04:25PM +0200, Harald Anlauf via Fortran wrote:
>
> Fortran allows functions in variable definition contexts when the
> result variable is a pointer. We already handle this for the
> non-CLASS case (in 11+), but the logic that checks the pointer
> attribute was looking
even building the flatbuffers repo externally using cmake at the same revision
didn't reproduce it.
that said, i have attached a dockerfile that shows you what /does/ fail, under
the specific conditions. but there is no unpatched libgcc_s, so you'll have
to do that part yourself, and build a libg
Ping. Ok for trunk ?
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-05-13 08:20
To: gcc-patches
CC: kito.cheng; palmer; jeffreyalaw; Juzhe-Zhong
Subject: [PATCH V5] RISC-V: Using merge approach to optimize repeating sequence
in vec_init
From: Juzhe-Zhong
1. Remove magic number of V4
2.
On 5/13/23 21:12, Andrew Pinski via Gcc-patches wrote:
This adds a simple pattern to match.pd for `signbit(x) ? x : -x`
into abs. This can be done for all types even ones that honor
signed zeros and NaNs because both signbit and - are considered
only looking at/touching the sign bit of those t
On 5/13/23 17:23, Bernhard Reutner-Fischer via Gcc-patches wrote:
From: Bernhard Reutner-Fischer
gcc/ada/ChangeLog:
* gcc-interface/decl.cc (gnat_to_gnu_entity): Use _P defines
from tree.h.
(constructor_address_p): Ditto.
(elaborate_expression_1): Ditto.
On Mon May 15, 2023 at 12:35 AM CEST, Thomas Neumann wrote:
> > even building the flatbuffers repo externally using cmake at the same
> > revision
> > didn't reproduce it.
> >
> > that said, i have attached a dockerfile that shows you what /does/ fail,
> > under
> > the specific conditions. but
The implementation is copied directly from ARM SVE.
I applied in my downstream GCC for a year and there is no issue so far.
Ok for trunk ?
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-05-13 19:44
To: gcc-patches
CC: kito.cheng; palmer; rdapp.gcc; jeffreyalaw; Juzhe-Zhong
Subject: [PATCH] R
On Fri, May 12, 2023 at 1:43 PM Hongtao Liu wrote:
>
> On Wed, May 10, 2023 at 5:10 PM liuhongt wrote:
> >
> > > The quoted patch shows -shared in context and you didn't post a
> > > backport version
> > > to look at. But yes, we shouldn't change -shared behavior on a
> > > branch, even less so
ping.
On Fri, Apr 21, 2023 at 9:55 PM liuhongt wrote:
>
> > > + if (!TARGET_SSE2)
> > > +{
> > > + if (c_dialect_cxx ()
> > > + && cxx_dialect > cxx20)
> >
> > Formatting, both conditions are short, so just put them on one line.
> Changed.
>
> > But for the C++23 macros, more impo
ping
On Fri, Apr 21, 2023 at 9:55 PM liuhongt wrote:
>
> > But for the C++23 macros, more importantly I think we really should
> > also in ix86_target_macros_internal add
> > if (c_dialect_cxx ()
> > && cxx_dialect > cxx20
> > && (isa_flag & OPTION_MASK_ISA_SSE2))
> > {
> >
From: Juzhe-Zhong
This patch implement decrement IV for length approach in loop control.
Address comment from kewen that incorporate the implementation inside
"vect_set_loop_controls_directly" instead of a standalone function.
Address comment from Richard using MIN_EXPR to handle these 3 follow
From: Juzhe-Zhong
This patch is to optimize the codegen of RVV VLS auto-vectorizaiton codegen due
to
alignment.
void __attribute__((noinline, noclone))
f3 (int * __restrict dst, int * __restrict op1, int * __restrict op2, int count)
{
for (int i = 0; i < count; ++i)
dst[i] = op1[i] + op2[
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index de578b5b899..a5776a550b2 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -7499,6 +7499,24 @@ riscv_preferred_simd_mode (scalar_mode mode)
>return word_mode;
> }
> +/* Implement target ho
Oh, I see. I try this way:
static poly_uint64
riscv_vectorize_preferred_vector_alignment (const_tree type)
{
if (riscv_v_ext_vector_mode_p (TYPE_MODE (type)))
return TYPE_ALIGN (TREE_TYPE (type));
return TYPE_ALIGN (type);
}
And disable both TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE
and
On Mon, May 15, 2023 at 10:48 AM juzhe.zh...@rivai.ai
wrote:
>
> Oh, I see. I try this way:
> static poly_uint64
> riscv_vectorize_preferred_vector_alignment (const_tree type)
> {
> if (riscv_v_ext_vector_mode_p (TYPE_MODE (type)))
> return TYPE_ALIGN (TREE_TYPE (type));
> return TYPE_ALIG
From: Pan Li
This patch support the RVV VREINTERPRET from the int to the vbool1_t. Aka:
vbool1_t __riscv_vreinterpret_xx_xx(v{u}int[8|16|32|64]_t);
These APIs help the users to convert vector LMUL=1 integer to vbool1_t.
According to the RVV intrinsic SPEC as below, the reinterpret intrinsics
o
From: Juzhe-Zhong
This patch optimizes both RVV VLA && VLS vectorization.
Consider this following case:
void __attribute__((noinline, noclone))
f (int * __restrict dst, int * __restrict op1, int * __restrict op2, int count)
{
for (int i = 0; i < count; ++i)
dst[i] = op1[i] + op2[i];
}
VLA
From: Juzhe-Zhong
This patch optimizes both RVV VLA && VLS vectorization.
Consider this following case:
void __attribute__((noinline, noclone))
f (int * __restrict dst, int * __restrict op1, int * __restrict op2, int count)
{
for (int i = 0; i < count; ++i)
dst[i] = op1[i] + op2[i];
}
VLA
Hi, address comment and send V2 patch here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618477.html
Thanks.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-05-15 10:56
To: juzhe.zh...@rivai.ai
CC: gcc-patches; palmer; Robin Dapp; jeffreyalaw
Subject: Re: Re: [PATCH] RISC-V: Support
T
The implementation LGTM.
But I am not sure testcase since we don't include any intrinsic API testcases
in GCC testsuite.
I think it needs Kito's decision.
Thanks.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-05-15 11:14
To: gcc-patches
CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang
Subj
Thanks Juzhe. Let's wait kito's suggestion.
Pan
From: juzhe.zh...@rivai.ai
Sent: Monday, May 15, 2023 11:20 AM
To: Li, Pan2 ; gcc-patches
Cc: Kito.cheng ; Li, Pan2 ; Wang,
Yanzhang
Subject: Re: [PATCH] RISC-V: Support RVV VREINTERPRET from v{u}int*_t to
vbool1_t
The implementation LGTM.
But
LGTM
於 2023年5月15日 週一 11:16 寫道：
> From: Juzhe-Zhong
>
> This patch optimizes both RVV VLA && VLS vectorization.
>
> Consider this following case:
> void __attribute__((noinline, noclone))
> f (int * __restrict dst, int * __restrict op1, int * __restrict op2, int
> count)
> {
> for (int i = 0;
Hi,
When running regression tests related to
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616772.html,
I noticed a bunch of failures because some tests explicitly pass in
-fdelete-null-pointer-checks, even if the target is configured to keep them.
This patch skips such failing tests by a
Thanks. Can you take a look at this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618398.html
This has been fixed 5 rounds. I already fixed it as you suggested
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-05-15 13:01
To: 钟居哲
CC: GCC Patches; Kito Cheng; Palmer Dabbelt; Palmer
Hi, this patch is very interesting patch and I found it's very beneficial after
applying to my downstream RVV GCC.
However, it has been a long time that this patch didn't update.
Is it possible that this patch will be refined and merged into trunk in the
future ?
Thanks
juzhe.zh...@rivai.ai
Hi kito,
Per off-line sync with Juzhe, I can help the rest part of this PATCH, will try
the suggested approach and keep you posted.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Saturday, May 13, 2023 11:14 AM
To: juzhe.zh...@rivai.ai
Cc: gcc-p
Committed, thanks kito.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Monday, May 15, 2023 1:01 PM
To: 钟居哲
Cc: GCC Patches ; Kito Cheng ;
Palmer Dabbelt ; Palmer Dabbelt ; Jeff
Law ; rdapp@gmail.co
Subject: Re: [PATCH V2] RISC-V: Support
Hi Carl,
on 2023/4/14 01:58, Carl Love via Gcc-patches wrote:
> GCC maintainers:
>
> The following fix updates the expected instruction counts for the
> test int_128bit-runnable.c test. The counts changed as a result of a
> commit to support 128-bit integer divide and modulus. The change
> res
Hi Carl,
on 2023/4/14 03:42, Carl Love via Gcc-patches wrote:
>
> GCC maintainers:
>
> The following patch fixes the dg-options for test powerpc/rs600-
> fpint.c. The test now works correctly on Power 10. The patch has been
> tested on Power10 with no regressions.
>
> Please let me know if th
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 it is ok for either
> 1 or 0; '||
54 matches
Mail list logo
