> -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.
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
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
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
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
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
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
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
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 =
+ 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
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;
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 =
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
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
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
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
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
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:
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
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
*
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
*
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
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
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
*
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
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
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):
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);
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
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
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
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
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
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
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
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
> -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]
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
> 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
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
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=
*
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
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
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
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
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:
*
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,
*
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
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,
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
>
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
> 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
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
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
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
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
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
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
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
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
Hi,
This is a v2 patch addressing feedback for:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621050.html
macOS SDK headers using the CF_ENUM macro can expand to invalid C++ code
of the form:
typedef enum T : BaseType T;
i.e. an elaborated-type-specifier with an additional enum-base.
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_get_max_nscalars_per_iter): Inline
> into ...
>
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 results in a vectorization factor that's bigger
> than the
Nit for test.
+/* { dg-options "-march=rv64gczve32x
+--param=riscv-autovec-preference=fixed-vlmax" } */
To
+/* { dg-options "-march=rv64gc_zve32x
--param=riscv-autovec-preference=fixed-vlmax" } */
Fixed in the V2 patch
(https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621698.html), thank
On Tue, 13 Jun 2023, Jakub Jelinek wrote:
> On Tue, Jun 13, 2023 at 08:40:36AM +, Richard Biener wrote:
> > I suspect re-association can wreck things even more here. I have
> > to say the matching code is very hard to follow, not sure if
> > splitting out a function matching
> >
> >_22
On Wed, 14 Jun 2023, Jakub Jelinek wrote:
> On Tue, Jun 13, 2023 at 01:29:04PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > > > + else if (addc_subc)
> > > > + {
> > > > + if (!integer_zerop (arg2))
> > > > + ;
> > > > + /* x = y + 0 + 0;
Nit for test.
+/* { dg-options "-march=rv64gczve32x
+--param=riscv-autovec-preference=fixed-vlmax" } */
To
+/* { dg-options "-march=rv64gc_zve32x
--param=riscv-autovec-preference=fixed-vlmax" } */
Pan
-Original Message-
From: Gcc-patches On Behalf
Of juzhe.zh...@rivai.ai
Sent:
PING
On Sat, Jun 10, 2023 at 10:30 PM Aldy Hernandez wrote:
>
>
>
> 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
PING
On Mon, May 22, 2023 at 8:56 PM Aldy Hernandez wrote:
>
> Minor cleanups to get rid of value_range in IPA. There's only one left,
> but it's in the switch code which is integer specific.
>
> OK?
>
> gcc/ChangeLog:
>
> * ipa-cp.cc (decide_whether_version_node): Adjust comment.
>
PING
On Mon, May 22, 2023 at 8:56 PM Aldy Hernandez wrote:
>
> This patch converts the ipa_jump_func code to use the type agnostic
> ipa_vr suitable for GC instead of value_range which is integer specific.
>
> I've disabled the range cacheing to simplify the patch for review, but
> it is handled
This patch fixes the link to README.Portability in "GCC Coding Conventions"
page
--
With the best regards
Jivan Hakobyan
diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index 9b6d243d..f5a356a8 100644
--- a/htdocs/codingconventions.html
+++
> 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 rewrite my tests.
Regards
Robin
1 - 100 of 175 matches
Mail list logo
