On Thu, 15 Jun 2023, Liu, Hongtao wrote:
>
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Wednesday, June 14, 2023 10:30 PM
> > To: Andrew Stubbs
> > Cc: gcc-patches@gcc.gnu.org; richard.sandif...@arm.com; Jan Hubicka
> > ; Liu, Hongtao ;
> > kirill.yuk...@gmail.com
> > Su
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609993.html
BR,
Kewen
on 2023/1/16 17:08, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As Honza pointed out in [1], the current uses of function
> optimize_function_for_speed_p in rs6000_option_override_internal
> are t
On 15.06.2023 07:23, Hongtao Liu wrote:
> On Wed, Jun 14, 2023 at 5:03 PM Jan Beulich wrote:
>>
>> On 14.06.2023 09:41, Hongtao Liu wrote:
>>> On Wed, Jun 14, 2023 at 1:58 PM Jan Beulich via Gcc-patches
>>> wrote:
... in vec_dupv4sf / *vec_dupv4si. The respective broadcast insns are
>>>
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_r
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 in
Oluwatamilore Adebayo writes:
> From: oluade01
>
> This adds a recognition pattern for the non-widening
> absolute difference (ABD).
>
> gcc/ChangeLog:
>
> * doc/md.texi (sabd, uabd): Document them.
> * internal-fn.def (ABD): Use new optab.
> * optabs.def (sabd_optab, uabd_optab
Richard Sandiford writes:
>> +
>> + /* Skip any newlines or whitespaces needed. */
>> + while (ISSPACE(*templ))
>> + templ++;
>> + continue;
>> + }
>> + else if (templ[0] == '/' && templ[1] == '*')
>> + {
>> + templ += 2;
>> + /*
Hi Carl,
on 2023/6/15 04:37, Carl Love wrote:
> Kewen, GCC maintainers:
>
> Version 4, added missing cases for new xxexpqp, xsxexpdp and xsxsigqp
> cases to rs6000_expand_builtin. Merged the new define_insn definitions
> with the existing definitions. Renamed the builtins by removing the
> __bu
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
From: chenxiaolong
Pushed r14-1831.
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 t
LGTM
juzhe.zh...@rivai.ai
From: shiyulong
Date: 2023-06-15 13:40
To: gcc-patches
CC: palmer; kito.cheng; jim.wilson.gcc; juzhe.zhong; pan2.li; wuwei2016;
jiawei; shihua; dje.gcc; mirimmad; yulong
Subject: [PATCH V1] RISC-V:Add float16 tuple type support
From: yulong
This patch adds support
The input constraint for the %vmovddup alternative was wrong, as the
upper 16 XMM registers require AVX512VL to be used with this insn. To
compensate, introduce a new alternative permitting all 32 registers, by
broadcasting to the full 512 bits in that case if AVX512VL is not
available.
gcc/
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, June 14, 2023 10:30 PM
> To: Andrew Stubbs
> Cc: gcc-patches@gcc.gnu.org; richard.sandif...@arm.com; Jan Hubicka
> ; Liu, Hongtao ;
> kirill.yuk...@gmail.com
> Subject: Re: [PATCH 3/3] AVX512 fully masked vectorization
>
>
From: yulong
This patch adds support for the float16 tuple type.
gcc/ChangeLog:
* config/riscv/genrvv-type-indexer.cc (valid_type): Enable FP16 tuple.
* config/riscv/riscv-modes.def (RVV_TUPLE_MODES): New macro.
(ADJUST_ALIGNMENT): Ditto.
(RVV_TUPLE_PARTIAL_MODES
On Thu, Jun 15, 2023 at 1:23 PM Hongtao Liu wrote:
>
> On Wed, Jun 14, 2023 at 5:03 PM Jan Beulich wrote:
> >
> > On 14.06.2023 09:41, Hongtao Liu wrote:
> > > On Wed, Jun 14, 2023 at 1:58 PM Jan Beulich via Gcc-patches
> > > wrote:
> > >>
> > >> ... in vec_dupv4sf / *vec_dupv4si. The respective
On Wed, Jun 14, 2023 at 5:32 PM Jan Beulich wrote:
>
> On 14.06.2023 10:10, Hongtao Liu wrote:
> > On Wed, Jun 14, 2023 at 1:59 PM Jan Beulich via Gcc-patches
> > wrote:
> >>
> >> There's no reason to constrain this to AVX512VL, as the wider operation
> >> is not usable for more narrow operands o
On Wed, Jun 14, 2023 at 5:03 PM Jan Beulich wrote:
>
> On 14.06.2023 09:41, Hongtao Liu wrote:
> > On Wed, Jun 14, 2023 at 1:58 PM Jan Beulich via Gcc-patches
> > wrote:
> >>
> >> ... in vec_dupv4sf / *vec_dupv4si. The respective broadcast insns are
> >> never longer (yet sometimes shorter) than
I think we all agree that __gnu_cxx::__ops needed to be reimplemented,
here it is.
Note that I kept the usage of std::ref in , and .
libstdc++: Reimplement __gnu_cxx::__ops operators
Replace functors using iterators as input to adopt functors that
are matching the same Standard ex
Hi Haochen,
on 2023/5/26 10:49, HAO CHEN GUI wrote:
> Hi,
> This patch adds a new insn for vector splat with small V2DI constants on P8.
> If the value of constant is in RANGE (-16, 15) and not 0 or -1, it can be
> loaded
> with vspltisw and vupkhsw on P8. It should be efficient than loading ve
From: Kyrylo Tkachov
Date: Wednesday, June 14, 2023 at 10:11 PM
To: Prathamesh Kulkarni , Tejas Belagod
Cc: Richard Sandiford , gcc-patches@gcc.gnu.org
Subject: RE: [PATCH v2] [PR96339] Optimise svlast[ab]
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gc
After several considerations, I think we may need to add VF_AUTO iterators
(with predicate TARGET_ZVFH for vector HF mode) for FP autovec.
Add add testcase of these unary operations with -march=rv64gc_zvfhmin to make
sure they don't
cause any ICE and vectorizations.
like https://gcc.gnu.org/pipe
LGTM thanks,.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-06-15 10:18
To: gcc-patches
CC: juzhe.zhong; palmer; rdapp.gcc; jeffreyalaw; kito.cheng
Subject: [PATCH v3] RISC-V: Use merge approach to optimize vector permutation
From: Juzhe-Zhong
This patch is to optimize the permuation case t
From: Juzhe-Zhong
This patch is to optimize the permuation case that is suiteable use
merge approach.
Consider this following case:
typedef int8_t vnx16qi __attribute__((vector_size (16)));
void __attribute__ ((noipa))
merge0 (vnx16qi x, vnx16qi y, vnx16qi *out)
{
vnx16qi v = __builtin_shuffl
+ for (int i = n_patterns; i < n_patterns * 2; i++)
+if (!d->perm.series_p (i, n_patterns, i, n_patterns)
+ && !d->perm.series_p (i, n_patterns, vec_len + i, n_patterns))
+ return false;
As Robin's suggested, Add comment here:
/* Check the pattern is monotonic here, otherwise, return fal
Addressed the comments in PATCH v2 as below.
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621789.html
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Jeff Law via Gcc-patches
Sent: Thursday, June 15, 2023 3:11 AM
To: Robin Dapp ; juzhe.zh...@rivai.ai;
gcc-patches@gcc.gnu.
From: Juzhe-Zhong
This patch is to optimize the permuation case that is suiteable use
merge approach.
Consider this following case:
typedef int8_t vnx16qi __attribute__((vector_size (16)));
void __attribute__ ((noipa))
merge0 (vnx16qi x, vnx16qi y, vnx16qi *out)
{
vnx16qi v = __builtin_shuffl
Committed with the comment update,, thanks Jeff and Juzhe.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Jeff Law via Gcc-patches
Sent: Thursday, June 15, 2023 3:08 AM
To: Lehua Ding ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; rdapp@gamil.com; jeffreya...@gamil.com;
Micro-architecture unconditionally treats a "jr $ra" as "return from
subroutine",
hence doing "jr $ra" would interfere with both subroutine return prediction and
the more general indirect branch prediction.
Therefore, a problem like PR110136 can cause a significant increase in branch
error
predi
From: Lehua Ding
The V2 patch address comments from Juzhe, thanks.
Hi,
The reason for this bug is that in the case where the vector register is set
to a fixed length (with `--param=riscv-autovec-preference=fixed-vlmax` option),
TARGET_PASS_BY_REFERENCE thinks that variables of type vint32m1 can
LGTM! Thanks!
在 2023/6/14 上午8:43, Xi Ruoyao 写道:
The LA464 micro-architecture is sensitive to alignment of code. The
Loongson team has benchmarked various combinations of function, the
results [1] show that 16-byte label alignment together with 32-byte
function alignment gives best results in te
Committed, thanks Jeff and Juzhe, sorry for misleading.
Pan
-Original Message-
From: Jeff Law
Sent: Thursday, June 15, 2023 2:51 AM
To: juzhe.zh...@rivai.ai; Li, Pan2 ; gcc-patches
Cc: Robin Dapp ; Wang, Yanzhang ;
kito.cheng
Subject: Re: [PATCH v1] RISC-V: Align the predictor style
Committed, thanks Jeff and Juzhe.
Pan
-Original Message-
From: Jeff Law
Sent: Thursday, June 15, 2023 2:56 AM
To: juzhe.zh...@rivai.ai; Li, Pan2 ; gcc-patches
Cc: Robin Dapp ; Wang, Yanzhang ;
kito.cheng
Subject: Re: [PATCH v3] RISC-V: Bugfix for vec_init repeating auto
vectorizati
On Linux/x86_64,
9c03391ba447ff86038d6a34c90ae737c3915b5f is the first bad commit
commit 9c03391ba447ff86038d6a34c90ae737c3915b5f
Author: Thomas Schwinge
Date: Wed Jun 7 16:24:26 2023 +0200
Tighten 'dg-warning' alternatives in
'c-c++-common/Wfree-nonheap-object{,-2,-3}.c'
caused
FAIL: c
Eric Gallager via Gcc-patches writes:
> On Wed, Jun 14, 2023 at 8:29 PM David Malcolm via Gcc-patches
> wrote:
>>
>> PR c++/110164 notes that in cases where we have a forward decl
>> of a std library type such as:
>>
>> std::array x;
>>
>> we omit this diagnostic:
>>
>> error: aggregate ‘std::a
On Wed, Jun 14, 2023 at 8:29 PM David Malcolm via Gcc-patches
wrote:
>
> PR c++/110164 notes that in cases where we have a forward decl
> of a std library type such as:
>
> std::array x;
>
> we omit this diagnostic:
>
> error: aggregate ‘std::array x’ has incomplete type and cannot be
> defined
>
PR c++/110164 notes that in cases where we have a forward decl
of a std library type such as:
std::array x;
we omit this diagnostic:
error: aggregate ‘std::array x’ has incomplete type and cannot be
defined
This patch adds this hint to the diagnostic:
note: ‘std::array’ is defined in header ‘
random_device::get_entropy() returns 0.0 when _GLIBCXX_USE_DEV_RANDOM
is not defined, but the test expects otherwise. Adjust.
Regstrapped on x86_64-linux-gnu, also tested on aarch64-rtems6. Ok to
install?
for libstdc++-v3/ChangeLog
* testsuite/26_numerics/random/random_device/entro
rtems, like vxworks, uses fast-float doubles for from_chars even for
long double, so it loses precision, so expect the long double bits to
fail on aarch64.
Regstrapped on x86_64-linux-gnu, also tested on aarch64-rtems6. Ok to
install?
for libstdc++-v3/ChangeLog
* testsuite/20_util/f
Contributing a patch by Joel Brobecker .
Regstrapped on x86_64-linux-gnu just to be sure, also tested with
aarch64-rtems6. I'm going to put this in later this week if there
aren't any objections.
When running the libstdc++ testsuite on AArch64 RTEMS, we noticed
that about 25 tests are failing
High-order bit: I've just committed OG13 version of these patches that is
integrated with Frederik's previous loop transformation patches that are
already on that branch. The OG13 version incorporates many of the suggestions
from this initial review plus a few bug fixes. I've also made corre
OpenMP 5.0 removed the restriction that multiple collapsed loops must
be perfectly nested, allowing "intervening code" (including nested
BLOCKs) before or after each nested loop. In GCC this code is moved
into the inner loop body by the respective front ends.
In the Fortran front end, most of the
This patch rearranges some code previously added to support loop
transformations to simplify merging support for imperfectly-nested loops
in a subsequent patch. There is no new functionality added here.
gcc/fortran/ChangeLog
* openmp.cc (find_nested_loop_in_chain): Move up in file.
OpenMP 5.0 removed the restriction that multiple collapsed loops must
be perfectly nested, allowing "intervening code" (including nested
BLOCKs) before or after each nested loop. In GCC this code is moved
into the inner loop body by the respective front ends.
This patch changes the C++ front end
gcc/testsuite/ChangeLog
* c-c++-common/gomp/imperfect1.c: New.
* c-c++-common/gomp/imperfect2.c: New.
* c-c++-common/gomp/imperfect3.c: New.
* c-c++-common/gomp/imperfect4.c: New.
* c-c++-common/gomp/imperfect5.c: New.
libgomp/ChangeLog
* testsuite/l
OpenMP 5.0 removed the restriction that multiple collapsed loops must
be perfectly nested, allowing "intervening code" (including nested
BLOCKs) before or after each nested loop. In GCC this code is moved
into the inner loop body by the respective front ends.
This patch changes the C front end to
I have pushed this set of patches to the OG13 development branch. The
major functional change compared to the mainline version I previously
posted on April 28 is that this version is integrated with Frederik's
loop transformation patches that were previously committed to this
branch. I've also in
The new internal clauses introduced for loop transformations were missing
from the big switch statements over all clauses in these functions.
gcc/ChangeLog:
* tree-nested.cc (convert_nonlocal_omp_clauses): Handle loop
transformation clauses.
(convert_local_omp_clauses): Lik
After several tries:
(define_mode_iterator VF_AUTO [
(VNx1HF "TARGET_ZVFH && TARGET_MIN_VLEN < 128")
(VNx2HF "TARGET_ZVFH")
(VNx4HF "TARGET_ZVFH")
(VNx8HF "TARGET_ZVFH")
(VNx16HF "TARGET_ZVFH")
(VNx32HF "TARGET_ZVFH && TARGET_MIN_VLEN > 32")
(VNx64HF "TARGET_ZVFH && TARGET_MIN_VLEN >
Hi, Jeff. Thanks for quick approval.
When I reviewed the patch:
(define_expand "2"
[(set (match_operand:VF 0 "register_operand")
(any_float_unop_nofrm:VF
(match_operand:VF 1 "register_operand")))]
"TARGET_VECTOR"
{
insn_code icode = code_for_pred (, mode);
riscv_vector::emit_vlma
In CLI project link to README is broken. This patch fixes that.
Discussed in PR110250
--
With the best regards
Jivan Hakobyan
diff --git a/htdocs/projects/cli.html b/htdocs/projects/cli.html
index 380fb031..394832b6 100644
--- a/htdocs/projects/cli.html
+++ b/htdocs/projects/cli.html
@@ -145,7 +
Kewen, GCC maintainers:
Version 4, added missing cases for new xxexpqp, xsxexpdp and xsxsigqp
cases to rs6000_expand_builtin. Merged the new define_insn definitions
with the existing definitions. Renamed the builtins by removing the
__builtin_ prefix from the names. Fixed the documentation for
Richard Biener writes:
> On Wed, 14 Jun 2023, Richard Sandiford wrote:
>
>> Richard Biener via Gcc-patches writes:
>> > The function is only meaningful for LOOP_VINFO_MASKS processing so
>> > inline it into the single use.
>> >
>> > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
>> >
>>
On 6/14/23 09:31, Robin Dapp wrote:
Hi,
this patch adds floating-point autovec expanders for vfneg, vfabs as well as
vfsqrt and the accompanying tests. vfrsqrt7 will be added at a later time.
So with vrsqrt7 I think the question turns into will we be able to use
it effectively. With its li
Tamar Christina writes:
> +The syntax rules are as follows:
> +@itemize @bullet
> +@item
> +Templates must start with @samp{@{@@} to use the new syntax.
> +
> +@item
> +@samp{@{@@} is followed by a layout in parentheses which is @samp{cons:}
s/parentheses/square brackets/
> +followed by a comma-
plonk.
On 26 May 2023 10:31:51 CEST, Bernhard Reutner-Fischer
wrote:
>On Thu, 25 May 2023 18:58:04 +0200
>Bernhard Reutner-Fischer wrote:
>
>> On Wed, 24 May 2023 18:54:06 +0100
>> "Roger Sayle" wrote:
>>
>> > My understanding is that GCC's preferred null value for rtx is NULL_RTX
>> > (and f
On 6/14/23 09:00, Robin Dapp wrote:
Hi Juzhe,
the general method seems sane and useful (it's not very complicated).
I was just distracted by
Selector = { 0, 17, 2, 19, 4, 21, 6, 23, 8, 9, 10, 27, 12, 29, 14, 31 }, the
common expression:
{ 0, nunits + 1, 1, nunits + 2, 2, nunits + 3, ... }
On 6/14/23 05:56, Lehua Ding wrote:
The V2 patch address comments from Juzhe, thanks.
Hi,
The reason for this bug is that in the case where the vector register is set
to a fixed length (with `--param=riscv-autovec-preference=fixed-vlmax` option),
TARGET_PASS_BY_REFERENCE thinks that varia
On 6/14/23 06:05, Robin Dapp via Gcc-patches wrote:
Oh. I see Robin's email is also wrong. CC Robin too for you
It still arrived via the mailing list ;)
Good to see a Fix patch of the ICE before Vector ABI patch.
Let's wait for more comments.
LGTM, this way I don't even need to rewri
On 6/14/23 06:01, juzhe.zh...@rivai.ai wrote:
LGTM now. Thanks for fixing it.
Good to see a Fix patch of the ICE before Vector ABI patch.
Let's wait for more comments.
Lehua Ding takes care of Vector ABI implementation and hopefully will
send it soon.
It seems the email of Jeff is wrong.
On 6/14/23 03:01, juzhe.zh...@rivai.ai wrote:
LGTM
Agreed. Commit when convenient.
jeff
On 6/14/23 01:23, juzhe.zh...@rivai.ai wrote:
LGTM
Likewise.
jeff
On 6/13/23 20:31, juzhe.zh...@rivai.ai wrote:
LGTM.
Similarly. If I've interpreted the thread correctly, there aren't any
issues created by this patch, though there are some existing issues that
need to be addressed independently. The patch itself is definitely the
right thing to be doing
Richard Biener via Gcc-patches writes:
> This implemens fully masked vectorization or a masked epilog for
> AVX512 style masks which single themselves out by representing
> each lane with a single bit and by using integer modes for the mask
> (both is much like GCN).
>
> AVX512 is also special in
On 6/14/23 03:14, Jivan Hakobyan via Gcc-patches wrote:
This patch removes a remnant of mudflap.
gcc/ChangeLog:
* config/moxie/uclinux.h (MFWRAP_SPEC): Remove
Thanks. I pushed this to the trunk.
jeff
ChangeLog:
* MAINTAINERS: Add myself to write after approval
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index c8b787b6e1e..4a9a656647e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -484,6 +484,7 @@ Kean Johnston
Phillip Jordan
Tim Josling
V
On Wed, Jun 14, 2023 at 06:25:10PM +0200, Richard Biener wrote:
> > Form rs6000.md:
> > ; This is to explain that changes to the stack pointer should
> > ; not be moved over loads from or stores to stack memory.
> > (define_insn "stack_tie"
>
> That suggests it’s the hard register value that‘s pro
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Prathamesh
> Kulkarni via Gcc-patches
> Sent: Wednesday, June 14, 2023 8:13 AM
> To: Tejas Belagod
> Cc: Richard Sandiford ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH v2] [PR96339] O
Hi!
On Wed, Jun 14, 2023 at 10:04:20AM +0100, Richard Sandiford wrote:
> I'd also understood it to be either. As in, it is a may-clobber
> that can be used for must-clobber. Alternatively: the value stored
> is unpredictable, and can therefore be the same as the current value.
Yes, it is a set
On Wed, Jun 14, 2023 at 09:22:09AM +, Richard Biener wrote:
> How can a clobber be validly dropped?
Same as any other set: if no code executed after it can read whatever is
written. This typically means a stack frame goes away, or simply no
more code is executed *at all* after this.
> For th
> Am 14.06.2023 um 17:41 schrieb Segher Boessenkool
> :
>
> Hi!
>
>> On Wed, Jun 14, 2023 at 07:59:04AM +, Richard Biener wrote:
>>> On Wed, 14 Jun 2023, Jiufu Guo wrote:
>>> 3. "set (mem/c:DI (reg/f:DI 1 1) unspec:DI (const_int 0 [0])
>>> UNSPEC_TIE".
>>> This avoids using BLK on unsp
On Tue, 2023-06-13 at 11:10 +0800, Kewen.Lin wrote:
> Hi Carl,
>
> on 2023/6/8 23:21, Carl Love wrote:
> > Kewen, GCC maintainers:
> >
> > Version 3, was able to get the overloaded version of
> > scalar_insert_exp
> > to work and the change to xsxexpqp_f128_ define instruction
> > to
> > work wit
It adjust preprocess, compile and link flags, which allows to change
default -lmsvcrt library by another provided by MinGW runtime.
gcc/
* config/i386/mingw-w64.h (CPP_SPEC): Adjust for -mcrtdll=.
(REAL_LIBGCC_SPEC): New define.
* config/i386/mingw.opt: Add mcrtdll=
* config/i3
Hi!
On Wed, Jun 14, 2023 at 09:52:37AM +, Richard Biener wrote:
> I see. So
>
> (parallel
> (unspec stack_tie)
> (clobber (mem:BLK ...)))
Written like this, without a "set", *every* unspec has to be an
unspec_volatile, for the same reason as all inline asms without outputs
always are cons
On Wed, Jun 14, 2023, at 10:52 AM, Joseph Myers wrote:
> On Tue, 13 Jun 2023, Paul Eggert wrote:
>
>> > There is always the possibility to have the header co-owned by both
>> > the compiler and C library, limits.h style. Just
>> > #if __has_include_next()
>> > # include_next
>> > #endif
>>
>> I do
Hi!
On Wed, Jun 14, 2023 at 05:26:52PM +0800, Jiufu Guo wrote:
> Richard Biener writes:
> >> 3. "set (mem/c:DI (reg/f:DI 1 1) unspec:DI (const_int 0 [0])
> >> UNSPEC_TIE".
> >>This avoids using BLK on unspec, but using DI.
> >
> > That gives the MEM a size which means we can interpret the (se
On 14.06.23 12:34, Tobias Burnus wrote:
Comments on the wording and/or the content?
This remains — however, the attached patch now additionally lists the
predefined allocators, fixes one awkward wording of mine – and it
documents the OpenMP 5.1 syntax of the OMP_ALLOCATOR environment variable.
Hi!
On Wed, Jun 14, 2023 at 07:59:04AM +, Richard Biener wrote:
> On Wed, 14 Jun 2023, Jiufu Guo wrote:
> > 3. "set (mem/c:DI (reg/f:DI 1 1) unspec:DI (const_int 0 [0])
> > UNSPEC_TIE".
> >This avoids using BLK on unspec, but using DI.
>
> That gives the MEM a size which means we can inte
Hi,
this patch adds floating-point autovec expanders for vfneg, vfabs as well as
vfsqrt and the accompanying tests. vfrsqrt7 will be added at a later time.
Similary to the binop tests, there are flavors for zvfh now. Prerequisites
as before.
Regards
Robin
gcc/ChangeLog:
* config/ris
Hi,
this implements the floating-point autovec expanders for binary
operations: vfadd, vfsub, vfdiv, vfmul, vfmax, vfmin and adds
tests.
The existing tests are amended and split up into non-_Float16
and _Float16 flavors as we cannot rely on the zvfh extension
being present.
As long as we do not
From: oluade01
This adds a recognition pattern for the non-widening
absolute difference (ABD).
gcc/ChangeLog:
* doc/md.texi (sabd, uabd): Document them.
* internal-fn.def (ABD): Use new optab.
* optabs.def (sabd_optab, uabd_optab): New optabs,
* tree-vect-pattern
On Wed, Jun 14, 2023 at 04:45:48PM +0200, Uros Bizjak wrote:
> +;; Helper peephole2 for the addcarry and subborrow
> +;; peephole2s, to optimize away nop which resulted from uaddc/usubc
> +;; expansion optimization.
> +(define_peephole2
> + [(set (match_operand:SWI48 0 "general_reg_operand")
> +
Hi!
On Wed, Jun 14, 2023 at 12:06:29PM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> I'm also thinking about other solutions:
> 1. "set (mem/c:BLK (reg/f:DI 1 1) (const_int 0 [0])"
> This is the existing pattern. It may be read as an action
> to clean an unknown-size memory block.
Hi!
On Wed, Jun 14, 2023 at 05:18:15PM +0800, Xi Ruoyao wrote:
> The generic issue here is to fix (not "papering over") the signed
> overflow, we need to perform the addition in a target machine mode. We
> may always use Pmode (IIRC const_anchor was introduced for optimizing
> some constant addre
On Wed, Jun 14, 2023 at 4:56 PM Jakub Jelinek wrote:
>
> On Wed, Jun 14, 2023 at 04:34:27PM +0200, Uros Bizjak wrote:
> > LGTM for the x86 part. I did my best, but those peephole2 patterns are
> > real PITA to be reviewed thoroughly.
> >
> > Maybe split out peephole2 pack to a separate patch, foll
Hi Juzhe,
the general method seems sane and useful (it's not very complicated).
I was just distracted by
> Selector = { 0, 17, 2, 19, 4, 21, 6, 23, 8, 9, 10, 27, 12, 29, 14, 31 }, the
> common expression:
> { 0, nunits + 1, 1, nunits + 2, 2, nunits + 3, ... }
>
> For this selector, we can use
On Wed, Jun 14, 2023 at 04:34:27PM +0200, Uros Bizjak wrote:
> LGTM for the x86 part. I did my best, but those peephole2 patterns are
> real PITA to be reviewed thoroughly.
>
> Maybe split out peephole2 pack to a separate patch, followed by a
> testcase patch. This way, bisection would be able to
On Tue, 13 Jun 2023, Paul Eggert wrote:
> > There is always the possibility to have the header co-owned by both
> > the compiler and C library, limits.h style.
> > Just
> > #if __has_include_next()
> > # include_next
> > #endif
>
> I don't see how you could implement __has_include_next() for
> a
On Wed, Jun 14, 2023 at 4:00 PM Jakub Jelinek wrote:
>
> Hi!
>
> On Wed, Jun 14, 2023 at 12:35:42PM +, Richard Biener wrote:
> > At this point two pages of code without a comment - can you introduce
> > some vertical spacing and comments as to what is matched now? The
> > split out functions
On Wed, Jun 14, 2023 at 4:00 PM Jakub Jelinek wrote:
>
> Hi!
>
> On Wed, Jun 14, 2023 at 12:35:42PM +, Richard Biener wrote:
> > At this point two pages of code without a comment - can you introduce
> > some vertical spacing and comments as to what is matched now? The
> > split out functions
> Am 14.06.2023 um 16:27 schrieb Andrew Stubbs :
>
> On 14/06/2023 12:54, Richard Biener via Gcc-patches wrote:
>> This implemens fully masked vectorization or a masked epilog for
>> AVX512 style masks which single themselves out by representing
>> each lane with a single bit and by using inte
> Am 14.06.2023 um 16:00 schrieb Jakub Jelinek :
>
> Hi!
>
>> On Wed, Jun 14, 2023 at 12:35:42PM +, Richard Biener wrote:
>> At this point two pages of code without a comment - can you introduce
>> some vertical spacing and comments as to what is matched now? The
>> split out functions h
On 14/06/2023 12:54, Richard Biener via Gcc-patches wrote:
This implemens fully masked vectorization or a masked epilog for
AVX512 style masks which single themselves out by representing
each lane with a single bit and by using integer modes for the mask
(both is much like GCN).
AVX512 is also s
Hi,
this introduces new checks for run tests. Currently we have
riscv_vector as well as rv32 and rv64 which all check if GCC (with the
current configuration) can build (not execute) the respective tests.
Many tests specify e.g. a different -march for vector, though. So the
check fails even thou
On Sat, 10 Jun 2023 at 23:04, Jonny Grant wrote:
>
> libstdc++-v3/ChangeLog:
>
> * doc/xml/manual/extensions.xml: Remove demangle exception
> description and include.
Thanks, pushed to trunk.
>
> ---
> libstdc++-v3/doc/xml/manual/extensions.xml | 6 ++
> 1 file changed, 2 insertions
In discussion of this issue CWG decided that the change of behavior on
well-formed code like overload-conv-4.C is undesirable. In further
discussion of possible resolutions, we discovered that we can avoid that
change while still getting the desired behavior on overload-conv-3.C by
making this a t
Hi!
On Wed, Jun 14, 2023 at 12:35:42PM +, Richard Biener wrote:
> At this point two pages of code without a comment - can you introduce
> some vertical spacing and comments as to what is matched now? The
> split out functions help somewhat but the code is far from obvious :/
>
> Maybe I'm co
On Wed, 14 Jun 2023, Jakub Jelinek wrote:
> On Wed, Jun 14, 2023 at 12:25:46PM +, Richard Biener wrote:
> > I think that's still very much desirable so this followup looks OK.
> > Maybe you can re-base it as prerequesite though?
>
> Rebased then (of course with the UADDC/USUBC handling remove
On Wed, Jun 14, 2023 at 12:25:46PM +, Richard Biener wrote:
> I think that's still very much desirable so this followup looks OK.
> Maybe you can re-base it as prerequesite though?
Rebased then (of course with the UADDC/USUBC handling removed from this
first patch, will be added in the second
On Wed, 14 Jun 2023, Richard Sandiford wrote:
> Richard Biener via Gcc-patches writes:
> > The function is only meaningful for LOOP_VINFO_MASKS processing so
> > inline it into the single use.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
> >
> > * tree-vect-loop.cc (vect_g
On Wed, 14 Jun 2023, Richard Sandiford wrote:
> Richard Biener via Gcc-patches writes:
> > Currently vect_determine_partial_vectors_and_peeling will decide
> > to apply fully masking to the main loop despite
> > --param vect-partial-vector-usage=1 when the currently analyzed
> > vector mode resul
1 - 100 of 176 matches
Mail list logo
