On 7/12/23 14:59, Jivan Hakobyan via Gcc-patches wrote:
Accessing local arrays element turned into load form (fp + (index <<
C1)) + C2 address. In the case when access is in the loop we got loop
invariant computation. For some reason, moving out that part cannot
be done in loop-invariant passe
Hi,
Here are the benchmarks for this change:
* is_fundamental
https://github.com/ken-matsui/gcc-benches/blob/main/is_fundamental.md#fri-jul-14-091146-pm-pdt-2023
Time: -37.1619%
Peak Memory Usage: -29.4294%
Total Memory Usage: -29.4783%
* is_fundamental_v
https://github.com/ken-matsui/gcc-ben
This patch optimizes the performance of the is_fundamental trait by
dispatching to the new __is_arithmetic built-in trait.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_fundamental_v): Use __is_arithmetic
built-in trait.
(is_fundamental): Likewise. Optimize the ori
This patch optimizes the performance of the is_arithmetic trait by
dispatching to the new __is_arithmetic built-in trait.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_arithmetic): Use __is_arithmetic
built-in trait.
(is_arithmetic_v): Likewise.
Signed-off-by: Ken
This patch implements built-in trait for std::is_arithmetic.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_arithmetic.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_ARITHMETIC.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.
gcc
Match will query ranger via tree_nonzero_bits/get_nonzero_bits for 2 and 3rd
operand of the COND_EXPR and phiopt tries to do create the COND_EXPR even if we
moving
one statement. That one statement could have some flow sensitive information on
it
based on the condition that is for the COND_EXPR b
This adds flow_sensitive_info_storage and uses it in
maybe_fold_comparisons_from_match_pd as mentioned in
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621817.html .
Since using it in maybe_fold_comparisons_from_match_pd was easy
and allowed me to test the storage earlier, I did it.
This als
This patch uses __bool_constant entirely instead of integral_constant
in the type_traits header, specifically for true_type, false_type,
and bool_constant.
libstdc++-v3/ChangeLog:
* include/std/type_traits (true_type): Use __bool_constant
instead.
(false_type): Likewise.
This patch introduces an attribute to add extra aliases to a symbol
when its definition is output. The main goal is to ease interfacing
C++ with Ada, as C++ mangled names have to be named, and in some cases
(e.g. when using stdint.h typedefs in function arguments) the symbol
names may vary acros
From: Ju-Zhe Zhong
Hi, Richard and Richi.
This patch adds mask_len_fold_left_plus pattern to support in-order
floating-point
reduction for target support len loop control.
Consider this following case:
double
foo2 (double *__restrict a,
double init,
int *__restrict cond,
int n)
On 7/14/23 11:16, Jason Merrill wrote:
I'm not seeing either a copyright assignment or DCO certification for
you; please see https://gcc.gnu.org/contribute.html#legal for more
information.
Oops, now I see the DCO sign-off, not sure how I was missing it.
Jason
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Apparently I wasn't actually running the testsuite in C++26 mode like I
thought I was, so there were some failures I wasn't seeing.
The constexpr hunk fixes regressions with the P2738 implementation; we still
need to use the old handling fo
On 7/13/23 09:20, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk and perhaps 13?
OK for both.
-- >8 --
This fixes a crash when mangling an ADL-enabled call to a template-id
naming an unknown template (as per P0846R0).
PR c++/11052
On 7/13/23 14:49, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
Here the call A().f() is represented as a COMPOUND_EXPR whose first
operand is the otherwise unused object argument A() and second operand
is the call result (b
On 7/14/23 14:07, Patrick Palka wrote:
On Thu, 13 Jul 2023, Jason Merrill wrote:
On 7/13/23 11:48, Patrick Palka wrote:
On Wed, 28 Jun 2023, Patrick Palka wrote:
On Wed, Jun 28, 2023 at 11:50 AM Jason Merrill wrote:
On 6/23/23 12:23, Patrick Palka wrote:
On Fri, 23 Jun 2023, Jason Merril
On 7/14/23 11:56, Richard Sandiford wrote:
Summary: We'd like to be able to specify some attributes using
keywords, rather than the traditional __attribute__ or [[...]]
syntax. Would that be OK?
In more detail:
We'd like to add some new target-specific attributes for Arm SME.
These attributes
On 7/14/23 09:37, Richard Biener wrote:
On Fri, 14 Jul 2023, Aldy Hernandez wrote:
I don't know what you're trying to accomplish here, as I haven't been
following the PR, but adding all these helper functions to the ranger header
file seems wrong, especially since there's only one use of them
I had messed up the case where the outer operator is `==`.
The check for the resulting should have been `==` and not `!=`.
This patch fixes that and adds a full runtime testcase now for
all cases to make sure it works.
OK? Bootstrapped and tested on x86-64-linux-gnu with no regressions.
gcc/Chang
On Thu, Jul 13, 2023 at 2:54 AM Richard Biener via Gcc-patches
wrote:
>
> The following makes sure that FP x > y ? x : y style max/min operations
> are if-converted at the GIMPLE level. While we can neither match
> it to MAX_EXPR nor .FMAX as both have different semantics with IEEE
> than the ter
On Fri, Jul 14, 2023 at 3:49 AM Jonathan Wakely wrote:
>
> On Fri, 14 Jul 2023 at 11:48, Jonathan Wakely wrote:
> >
> > On Thu, 13 Jul 2023 at 21:04, Ken Matsui wrote:
> > >
> > > On Thu, Jul 13, 2023 at 2:22 AM Jonathan Wakely
> > > wrote:
> > > >
> > > > On Wed, 12 Jul 2023 at 21:42, Ken Mat
On Fri, Jul 14, 2023 at 11:56 AM Roger Sayle wrote:
>
>
>
> This patch fixes the bootstrap failure I'm seeing using gcc 4.8.5 as
>
> the host compiler. Ok for mainline? [I might be missing something]
I think adding const here makes this well defined C++20 too.
See http://cplusplus.github.io/LWG
This patch fixes the bootstrap failure I'm seeing using gcc 4.8.5 as
the host compiler. Ok for mainline? [I might be missing something]
2023-07-14 Roger Sayle
gcc/ChangeLog
* tree-if-conv.cc (predicate_scalar_phi): Make the arguments
to the std::sort comparison
On Thu, 13 Jul 2023, Jason Merrill wrote:
> On 7/13/23 11:48, Patrick Palka wrote:
> > On Wed, 28 Jun 2023, Patrick Palka wrote:
> >
> > > On Wed, Jun 28, 2023 at 11:50 AM Jason Merrill wrote:
> > > >
> > > > On 6/23/23 12:23, Patrick Palka wrote:
> > > > > On Fri, 23 Jun 2023, Jason Merrill wr
On Fri, Jul 14, 2023 at 04:56:18PM +0100, Richard Sandiford via Gcc-patches
wrote:
> Summary: We'd like to be able to specify some attributes using
> keywords, rather than the traditional __attribute__ or [[...]]
> syntax. Would that be OK?
Will defer to C/C++ maintainers, but as you mentioned,
On 7/13/23 14:54, Marek Polacek wrote:
On Fri, May 26, 2023 at 09:47:10PM -0400, Jason Merrill wrote:
On 5/26/23 19:18, Marek Polacek wrote:
The is_really_empty_class check is sort of non-obvious but the
comment should explain why I added it.
+ /* When there's nothing to initializ
This patch fixes a bug in non-contiguous 'target update' operations using
the new array-shaping operator for C and C++, processing the dimensions
of the array the wrong way round during the OpenMP lowering pass.
Fortran was also incorrectly using the wrong ordering but the second
reversal in omp-lo
This patch enables the c-c++-common/gomp/declare-mapper-3.c test for C.
This was seemingly overlooked in commit 393fd99c90e.
Tested with offloading to AMD GCN. I will apply (to og13) shortly.
2023-07-14 Julian Brown
gcc/testsuite/
* c-c++-common/gomp/declare-mapper-3.c: Enable for C.
> -Original Message-
> From: Christophe Lyon
> Sent: Thursday, July 13, 2023 11:22 AM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> Richard Earnshaw ; Richard Sandiford
>
> Cc: Christophe Lyon
> Subject: [PATCH 1/6] arm: [MVE intrinsics] Factorize vcaddq vhcaddq
>
> Factorize vca
Summary: We'd like to be able to specify some attributes using
keywords, rather than the traditional __attribute__ or [[...]]
syntax. Would that be OK?
In more detail:
We'd like to add some new target-specific attributes for Arm SME.
These attributes affect semantics and code generation and so t
> -Original Message-
> From: Christophe Lyon
> Sent: Thursday, July 13, 2023 11:22 AM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> Richard Earnshaw
> Cc: Christophe Lyon
> Subject: [PATCH 2/2] [testsuite,arm]: Make mve_fp_fpu[12].c accept single or
> double precision FPU
>
> Thi
> -Original Message-
> From: Christophe Lyon
> Sent: Thursday, July 13, 2023 11:22 AM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> Richard Earnshaw
> Cc: Christophe Lyon
> Subject: [PATCH 1/2] [testsuite,arm]: Make nomve_fp_1.c require arm_fp
>
> If GCC is configured with the de
On 6/30/23 23:28, Nathaniel Shead via Gcc-patches wrote:
This adds rudimentary lifetime tracking in C++ constexpr contexts,
Thanks!
I'm not seeing either a copyright assignment or DCO certification for
you; please see https://gcc.gnu.org/contribute.html#legal for more
information.
diff --
>>> Can you add testcases? Also the current restriction is because
>>> the variants you add are not always correct and I don't see any
>>> checks that the intermediate type doesn't lose significant bits?
I didn't manage to create one for aarch64 nor for x86 because AVX512
has direct conversions e
Our checks for whether the vectorization of a given loop would make an
out of bounds access miss the case when the vector we load is so large
as to span multiple iterations worth of data (while only being there to
implement a single iteration).
This patch adds a check for such an access.
Example
Hi,
currently we rebuild profile_counts from profile_probability after inlining,
because there is a chance that producing large loop nests may get
unrealistically
large profile_count values. This is much less of concern when we switched to
new profile_count representation while back.
This propag
On 7/14/23 15:37, Richard Biener wrote:
On Fri, 14 Jul 2023, Aldy Hernandez wrote:
I don't know what you're trying to accomplish here, as I haven't been
following the PR, but adding all these helper functions to the ranger header
file seems wrong, especially since there's only one use of the
On Fri, 14 Jul 2023, Aldy Hernandez wrote:
> I don't know what you're trying to accomplish here, as I haven't been
> following the PR, but adding all these helper functions to the ranger header
> file seems wrong, especially since there's only one use of them. I see you're
> tweaking the irange AP
On Thu, 13 Jul 2023, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Thursday, July 13, 2023 6:31 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> > Subject: Re: [PATCH 12/19]middle-end: implement loop peeling and I
From: Pan Li
Refine the run test case to avoid interactive checking in RV32, by
separating each checks in different functions.
Signed-off-by: Pan Li
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/float-point-frm-run-1.c: Fix failure
on RV32.
---
.../riscv/rvv/base/float
Committed, thanks Kito and Robin.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Friday, July 14, 2023 8:33 PM
To: Robin Dapp
Cc: Juzhe-Zhong ; GCC Patches ;
Kito Cheng ; Palmer Dabbelt ; Jeff
Law
Subject: Re: [PATCH V2] RISC-V: Enable COND_LE
So to be safe, I think it should be backport to GCC 13 even though I didn't
have a intrinsic testcase to reproduce it.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-14 20:38
To: 钟居哲
CC: GCC Patches; Kito Cheng; Palmer Dabbelt; Robin Dapp; Jeff Law
Subject: Re: [PATCH] RISC-V: Support no
>> It's performance bug or correctness bug? Does it's also appeared in gcc 13
>> if it's a correctness bug?
It's correctness bug.
The bug as below:
vsetvli zero, 1, e16, m1, ta, ma > VSETVL pass detect it can be fused as
"t1,zero,e16,m2,ta,ma" but failed in change_insn
vmv.s.x v1,a5
...
於 2023年7月14日 週五 20:31 寫道：
> From: Ju-Zhe Zhong
>
> This patch add reduc_*_scal to support reduction auto-vectorization.
>
> Use COND_LEN_* + reduc_*_scal to support unordered non-SLP
> auto-vectorization.
>
> Consider this following case:
> int __attribute__((noipa))
> and_loop (int32_t * __rest
LGTM
Robin Dapp via Gcc-patches 於 2023年7月14日 週五 15:05
寫道：
> Hi Juzhe,
>
> thanks, looks good to me now - did before already actually ;).
>
> Regards
> Robin
>
Committed :)
Jeff Law via Gcc-patches 於 2023年7月14日 週五 10:52 寫道：
>
>
> On 7/13/23 20:41, Kito Cheng via Gcc-patches wrote:
> > Expanding without DONE or FAIL will leave the pattern as well, so this
> > patch is fine IMO, so this patch LGTM, but anyway I will test this and
> > commit if passed :)
From: Ju-Zhe Zhong
This patch add reduc_*_scal to support reduction auto-vectorization.
Use COND_LEN_* + reduc_*_scal to support unordered non-SLP auto-vectorization.
Consider this following case:
int __attribute__((noipa))
and_loop (int32_t * __restrict x,
int32_t n, int res)
{
for (int i =
Hi,
loop-ch currently does analysis using ranger for all loops to identify
candidates and then follows by phase where headers are duplicated (which
breaks SSA and ranger). The second stage does more analysis (to see how
many BBs we want to duplicate) but can't use ranger and thus misses
informatio
commit 53d12ecd624ec901d8449cfa1917f6f90e910927 (HEAD -> master, origin/master,
origin/HEAD)
Author: Jose E. Marchesi
Date: Fri Jul 14 13:54:06 2023 +0200
bpf: enable instruction scheduling
This patch adds a dummy FSM to bpf.md in order to get INSN_SCHEDULING
defined. If th
I don't know what you're trying to accomplish here, as I haven't been
following the PR, but adding all these helper functions to the ranger
header file seems wrong, especially since there's only one use of them.
I see you're tweaking the irange API, adding helper functions to
range-op (which is
On 7/12/23 23:50, Jeff Law wrote:
On 7/12/23 15:15, Aldy Hernandez via Gcc-patches wrote:
This patch teaches popcount about known set bits which are now
available in the irange.
PR tree-optimization/107053
gcc/ChangeLog:
* gimple-range-op.cc (cfn_popcount): Use known set bits.
g
When looking at the documentation, I found some more gaps and a missing
cross ref between OMP_ALLOCATOR and the 'Memory allocation' section.
Hence, I applied the attached patch as r14-2518-ga85a106c35c6d1
For more documentation tasks, see for instance: https://gcc.gnu.org/PR110364
Tobias
--
On Fri, 14 Jul 2023 at 11:48, Jonathan Wakely wrote:
>
> On Thu, 13 Jul 2023 at 21:04, Ken Matsui wrote:
> >
> > On Thu, Jul 13, 2023 at 2:22 AM Jonathan Wakely wrote:
> > >
> > > On Wed, 12 Jul 2023 at 21:42, Ken Matsui
> > > wrote:
> > > >
> > > > On Wed, Jul 12, 2023 at 3:01 AM Jonathan Wak
On Thu, 13 Jul 2023 at 21:04, Ken Matsui wrote:
>
> On Thu, Jul 13, 2023 at 2:22 AM Jonathan Wakely wrote:
> >
> > On Wed, 12 Jul 2023 at 21:42, Ken Matsui wrote:
> > >
> > > On Wed, Jul 12, 2023 at 3:01 AM Jonathan Wakely
> > > wrote:
> > > >
> > > > On Mon, 10 Jul 2023 at 06:51, Ken Matsui v
On 14.07.2023 12:10, Uros Bizjak wrote:
> On Fri, Jul 14, 2023 at 11:44 AM Jan Beulich wrote:
>>
>> The corresponding insn serves this purpose quite fine, and leads to
>> slightly less (generated) code. All we need is the insn to not have a
>> leading * in its name, while retaining that * for "ext
Hi Thomas,
On 2023/6/23 6:47 PM, Thomas Schwinge wrote:
>> +
>>ctx->clauses = *orig_list_p;
>>gimplify_omp_ctxp = ctx;
>> }
> Instead of this, in 'gimplify_omp_workshare', before the
> 'gimplify_scan_omp_clauses' call, do something like:
>
> if ((ort & ORT_ACC)
> && !omp_find
Why didn't you test that?
../../gcc/config/riscv/riscv.cc: In function 'int
riscv_regno_ok_for_index_p(int)':
../../gcc/config/riscv/riscv.cc:864:33: error: unused parameter 'regno'
[-Werror=unused-parameter]
864 | riscv_regno_ok_for_index_p (int regno)
|
On 7/13/23 4:05 PM, Richard Biener wrote:
On Thu, Jul 13, 2023 at 12:15 PM Tejas Belagod wrote:
On 7/3/23 1:31 PM, Richard Biener wrote:
On Mon, Jul 3, 2023 at 8:50 AM Tejas Belagod wrote:
On 6/29/23 6:55 PM, Richard Biener wrote:
On Wed, Jun 28, 2023 at 1:26 PM Tejas Belagod wrote:
On Fri, Jul 14, 2023 at 11:44 AM Jan Beulich wrote:
>
> The corresponding insn serves this purpose quite fine, and leads to
> slightly less (generated) code. All we need is the insn to not have a
> leading * in its name, while retaining that * for "extendhfsf2".
> Introduce a mode attribute in exc
On Fri, Jul 14, 2023 at 11:27 AM Roger Sayle wrote:
>
>
> > From: Uros Bizjak
> > Sent: 13 July 2023 19:21
> >
> > On Thu, Jul 13, 2023 at 7:10 PM Roger Sayle
> > wrote:
> > >
> > > This patch resolves PR target/110588 to catch another case in combine
> > > where the i386 backend should be gener
On Fri, Jul 14, 2023 at 10:53 AM Richard Biener wrote:
>
> On Fri, 14 Jul 2023, Uros Bizjak wrote:
>
> > On Fri, Jul 14, 2023 at 10:31?AM Richard Biener wrote:
> > >
> > > On Fri, 14 Jul 2023, Uros Bizjak wrote:
> > >
> > > > cprop1 pass does not consider paradoxical subreg and for (insn 22)
> >
The corresponding insn serves this purpose quite fine, and leads to
slightly less (generated) code. All we need is the insn to not have a
leading * in its name, while retaining that * for "extendhfsf2".
Introduce a mode attribute in exchange to achieve that.
gcc/
* config/i386/i386.md (ex
In the (however unlikely) event that no insn can be found for the
requested mode, using maybe_gen_...() without (really) checking its
result for being a null rtx would lead to silent bad code generation.
gcc/
* config/i386/i386-expand.cc (ix86_expand_vector_init_duplicate):
Use ge
Introduce a new alternative permitting all 32 registers to be used as
source without AVX512VL, by broadcasting to the full 512 bits in that
case. (The insn would also permit all registers to be used as
destination, but V2DFmode doesn't.)
gcc/
* config/i386/sse.md (vec_dupv2df): Add new AV
> From: Uros Bizjak
> Sent: 13 July 2023 19:21
>
> On Thu, Jul 13, 2023 at 7:10 PM Roger Sayle
> wrote:
> >
> > This patch resolves PR target/110588 to catch another case in combine
> > where the i386 backend should be generating a btl instruction. This
> > adds another define_insn_and_split
On Thu, 13 Jul 2023, Richard Biener wrote:
> On Wed, 28 Jun 2023, Tamar Christina wrote:
>
> > Hi All,
> >
> > For early break vectorization we have to update niters analysis to record
> > and
> > analyze all exits of the loop, and so all conds.
> >
> > The niters of the loop is still determin
On Fri, 14 Jul 2023, Uros Bizjak wrote:
> On Fri, Jul 14, 2023 at 10:31?AM Richard Biener wrote:
> >
> > On Fri, 14 Jul 2023, Uros Bizjak wrote:
> >
> > > cprop1 pass does not consider paradoxical subreg and for (insn 22) claims
> > > that it equals 8 elements of HImodeby setting REG_EQUAL note:
On Fri, Jul 14, 2023 at 10:31 AM Richard Biener wrote:
>
> On Fri, 14 Jul 2023, Uros Bizjak wrote:
>
> > cprop1 pass does not consider paradoxical subreg and for (insn 22) claims
> > that it equals 8 elements of HImodeby setting REG_EQUAL note:
> >
> > (insn 21 19 22 4 (set (reg:V4QI 98)
> >
The following adds checking that the edge we query an associated
PHI arg for is related to the PHI node. Triggered by questionable
code in one of my reviews.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* gimple.h (gimple_phi_arg): New const overload.
(gimple_phi_
On Fri, 14 Jul 2023, Uros Bizjak wrote:
> cprop1 pass does not consider paradoxical subreg and for (insn 22) claims
> that it equals 8 elements of HImodeby setting REG_EQUAL note:
>
> (insn 21 19 22 4 (set (reg:V4QI 98)
> (mem/u/c:V4QI (symbol_ref/u:DI ("*.LC1") [flags 0x2]) [0 S4
> A32]
Pinging to try and get this bug in gcc-ar fixed.
Note that the patch posted as an attachment in
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623400.html
is exactly the same as the patch embedded in
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623855.html
and the one posted in the
On Thu, Jul 13, 2023 at 6:45 PM Roger Sayle wrote:
>
>
> This is the next piece towards a fix for (the x86_64 ABI issues affecting)
> PR 88873. This patch generalizes the recent tweak to ix86_expand_move
> for setting the highpart of a TImode reg from a DImode source using
> *insvti_highpart_1, t
Hi Prathamesh,
On 13.07.23 18:13, Prathamesh Kulkarni wrote:
The newly added tests in above commit -- alloc-11.c and alloc-12.c
seem to fail during execution on armv8l-unknown-linux-gnueabihf:
thanks for the report and sorry for the breakage. While being aware that
libnuma is potentially not
On Fri, Jul 14, 2023 at 8:24 AM Haochen Jiang wrote:
>
> Hi all,
>
> This patch aims to auto vectorize usdot_prod and udot_prod with newly
> introduced AVX-VNNI-INT16.
>
> Also I refined the redundant mode iterator in the patch.
>
> Regtested on x86_64-pc-linux-gnu. Ok for trunk after AVX-VNNI-INT
Corresponding PR on c-api-doc under discussion, so defer this until
that settles down :)
https://github.com/riscv-non-isa/riscv-c-api-doc/pull/46
On Thu, Jul 13, 2023 at 1:40 PM Monk Chiang via Gcc-patches
wrote:
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_print_operand
Committed, thanks :)
On Thu, Jul 13, 2023 at 1:39 PM Monk Chiang via Gcc-patches
wrote:
>
> gcc/ChangeLog:
>
> * common/config/riscv/riscv-common.cc:
> (riscv_implied_info): Add zihintntl item.
> (riscv_ext_version_table): Ditto.
> (riscv_ext_fl
Hi Juzhe,
thanks, looks good to me now - did before already actually ;).
Regards
Robin
76 matches
Mail list logo
