On Fri, May 26, 2023 at 4:59 AM Andrew Pinski via Gcc-patches
wrote:
>
> This is based on the review of
> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619342.html .
> Instead of emitting debug message even if we don't apply a pattern, this
> fixes the issue
> by only emitting it if it the
On Fri, 26 May 2023, ??? wrote:
> Yesterday's patch has been approved (decremnt IV support):
> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619663.html
>
> However, it creates fails on PowerPC:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109971
>
> I am really sorry for causing inconv
> I realize that both TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES and
> TARGET_VECTORIZE_RELATED_MODE will partially enable some
> auto-vectorization even preferred_simd_mode does not enable
> auto-vectorization when we don't specify
> --param=riscv-autovec-preference.
>
> So plz add autovec_use_v
Thanks Robin.
Sorry for not mentioned that it depends on another patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619536.html, which is in the
reviewing queue.
Yes, totally agree we can remove the comments for some parameters excepts the
Boolean ones, as well as the term data related.
Hi,
> This patch would like to remove the magic number in the riscv-v.cc, and
> align the same value to one macro.
> diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
> index 458020ce0a1..20b589bf51b 100644
> --- a/gcc/config/riscv/riscv-v.cc
> +++ b/gcc/config/riscv/riscv-v.
When testing a extension, it is often necessary for a certain program not to
need some kind of extension, such as the bitmanip extension, to evaluate the
performance or codesize of the extension. However, the current multilib rules
will report an error when it is not a superset of the MULTILIB_REQU
On Fri, May 26, 2023 at 4:46 AM liuhongt wrote:
>
> lzcnt/tzcnt has been fixed since skylake, popcnt has been fixed since
> icelake. At least for icelake and later intel Core processors, the
> errata tune is not needed. And the tune isn't need for ATOM either.
>
> Bootstrapped and regtested on x86
On Fri, May 26, 2023 at 4:12 AM Jiang, Haochen wrote:
>
> > gcc/ChangeLog:
> >
> > * config/i386/i386-expand.cc (ix86_expand_vecop_qihi2):
> > Rewrite to expand to 2x-wider (e.g. V16QI -> V16HImode)
> > instructions when available. Emulate truncation via
> > ix86_expand_vec_perm_c
On 5/25/23 20:43, Kito Cheng wrote:
I would defer this to vrull or t-head folks :)
Given the overlap between where this is going and how I think we should
be handling Zicondops, I'll take it. It overlaps with work I've had
Raphael doing recently.
jeff
On Thu, 25 May 2023 at 15:26, Prathamesh Kulkarni
wrote:
>
> On Thu, 25 May 2023 at 13:04, Richard Sandiford
> wrote:
> >
> > LGTM, just a couple of comment tweaks:
> >
> > Prathamesh Kulkarni writes:
> > > diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> > > index d6
From: Juzhe-Zhong
Fix bug reported here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109974
PR target/109974
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (source_equal_p): Fix ICE.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/vsetvl/pr109974.c: New test.
---
gc
This is based on the review of
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619342.html .
Instead of emitting debug message even if we don't apply a pattern, this fixes
the issue
by only emitting it if it the pattern finally succeeded.
OK? Bootstrapped and tested on x86_64-linux-gnu with n
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 vector from
memory.
Compared to last version, the main change i
lzcnt/tzcnt has been fixed since skylake, popcnt has been fixed since
icelake. At least for icelake and later intel Core processors, the
errata tune is not needed. And the tune isn't need for ATOM either.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready to push to trunk.
gcc/Chang
I would defer this to vrull or t-head folks :)
Die Li 於 2023年5月26日 週五 08:53 寫道：
> This patch allows less instructions to be used when TARGET_XTHEADCONDMOV
> is enabled.
>
> Provide an example from the existing testcases.
>
> Testcase:
> int ConEmv_imm_imm_reg(int x, int y){
> if (x == 1000) re
> gcc/ChangeLog:
>
> * config/i386/i386-expand.cc (ix86_expand_vecop_qihi2):
> Rewrite to expand to 2x-wider (e.g. V16QI -> V16HImode)
> instructions when available. Emulate truncation via
> ix86_expand_vec_perm_const_1 when native truncate insn
> is not available.
> (ix86
r12-5595-gc39d77f252e895306ef88c1efb3eff04e4232554 adds 2 splitter to
transform notl + pbroadcast + pand to pbroadcast + pandn for
VI124_AVX2 which leaves out all DI-element-size ones as
well as all 512-bit ones.
This patch extend the splitter to VI_AVX2 which will handle DImode for
AVX2, and V64QI
Committed the PATCH v2, thanks Kito.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Friday, May 26, 2023 7:48 AM
To: 钟居哲
Cc: GCC Patches ; Jeff Law ;
Jeff Law ; Kito Cheng ; Palmer
Dabbelt
Subject: Re: [PATCH] RISC-V: Fix zero-scratch-regs-3.c
I realize that both TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES and
TARGET_VECTORIZE_RELATED_MODE
will partially enable some auto-vectorization even preferred_simd_mode does not
enable auto-vectorization
when we don't specify --param=riscv-autovec-preference.
So plz add autovec_use_vlmax_p
into
This patch allows less instructions to be used when TARGET_XTHEADCONDMOV is
enabled.
Provide an example from the existing testcases.
Testcase:
int ConEmv_imm_imm_reg(int x, int y){
if (x == 1000) return 10;
return y;
}
Cflags:
-O2 -march=rv64gc_xtheadcondmov -mabi=lp64d
before patch:
ConEm
From: Pan Li
This patch would like to remove the magic number in the riscv-v.cc, and
align the same value to one macro.
Signed-off-by: Pan Li
gcc/ChangeLog:
* config/riscv/riscv-v.cc (emit_vlmax_insn): Eliminate the
magic number.
(emit_nonvlmax_insn): Ditto.
(e
From: Juzhe-Zhong
gcc/ChangeLog:
* config/riscv/riscv.cc (vector_zero_call_used_regs): Add explict VL
and drop VL in ops.
---
gcc/config/riscv/riscv.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 0
Looks Juzhe has fixed this issue as below, thanks Juzhe.
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619733.html
Pan
-Original Message-
From: Li, Pan2
Sent: Thursday, May 25, 2023 8:22 PM
To: gcc-patches ; Wang, Yanzhang
Cc: Robin Dapp ; Kito Cheng ; palmer
; juzhe.zh...@rivai
> On May 25, 2023, at 4:51 PM, Joseph Myers wrote:
>
> The documentation in this case is OK, though claims about how a future
> version will behave have a poor track record (we tend to end up with such
> claims persisting in the documentation even though the change in question
> didn't get
On 5/25/23 14:17, Vineet Gupta wrote:
Thanks for taking a look at this. Please don't get me wrong, never
mean to vilify the patches above - and I should have verified first
(by reverting those) if they caused the issue - if at all. It just
seemed that we started seeing these relatively recen
On 5/25/23 13:29, Thomas Schwinge wrote:
Hi!
On 2023-05-17T09:52:13+0200, Andreas Schwab via Gcc-patches
wrote:
On Mai 16 2023, Vineet Gupta wrote:
Yes I was seeing similar tcl errors and such - and in my case an even
higher count.
They are coming from commit d6654a4be3b.
I call FUD.
Lgtm with a minor comment
於 2023年5月26日 週五 07:18 寫道：
> From: Juzhe-Zhong
>
> Fix ICE of zero-scratch-regs-3.c:
> bug.c:7:1: internal compiler error: Segmentation fault
> 7 | }
> | ^
> 0x1647b23 crash_signal
> ../../../riscv-gcc/gcc/toplev.cc:314
> 0x147053f maybe_legitimize_ope
From: Juzhe-Zhong
Fix ICE of zero-scratch-regs-3.c:
bug.c:7:1: internal compiler error: Segmentation fault
7 | }
| ^
0x1647b23 crash_signal
../../../riscv-gcc/gcc/toplev.cc:314
0x147053f maybe_legitimize_operand
../../../riscv-gcc/gcc/optabs.cc:7947
0x1470dc2 maybe_legit
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The Cpp17Allocator requirements say that an allocator's pointer and
const_pointer types must meet the Cpp17RandomAccessIterator
requirements. That means our PointerBase helper for defining fancy
pointer types should support the full set of relational
LGTM this patch. Let's wait for kito's final approval.
Thanks.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-05-25 22:43
To: 钟居哲; gcc-patches; kito.cheng; palmer; Jeff Law
CC: rdapp.gcc
Subject: Re: [PATCH v2] RISC-V: Implement autovec abs, vneg, vnot.
> Beside, V2 patch should change this:
Yesterday's patch has been approved (decremnt IV support):
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619663.html
However, it creates fails on PowerPC:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109971
I am really sorry for causing inconvinience.
I wonder as we disccussed:
+ /* If w
On 5/25/23 14:17, Vineet Gupta wrote:
FWIW if you want to test this out at your end, it is super easy.
|git clone https://github.com/riscv-collab/riscv-gnu-toolchain
toolchain-upstream cd toolchain-upstream git submodule init git
submodule update ||./configure --with-arch=rv64imafdc --with-a
Hi Thomas,
On 5/25/23 13:56, Thomas Schwinge wrote:
Hi!
On 2022-02-08T00:22:37+0800, Kito Cheng via Gcc-patches
wrote:
Hi Maciej:
Thanks for doing this, OK to trunk.
On Tue, Feb 1, 2022 at 7:04 AM Maciej W. Rozycki wrote:
Use `gcc-dg-runtest' test driver rather than `dg-runtest' to run t
What happens if the field giving the number of elements is in a contained
anonymous structure or union?
struct s {
struct { size_t count; };
int array[] __attribute__ ((element_count ("count")));
};
This ought to work - a general principle in C is that anonymous structures
and unions are tr
Hi!
On 2022-02-08T00:22:37+0800, Kito Cheng via Gcc-patches
wrote:
> Hi Maciej:
>
> Thanks for doing this, OK to trunk.
>
> On Tue, Feb 1, 2022 at 7:04 AM Maciej W. Rozycki wrote:
>>
>> Use `gcc-dg-runtest' test driver rather than `dg-runtest' to run the
>> RISC-V testsuite as several targets a
The documentation in this case is OK, though claims about how a future
version will behave have a poor track record (we tend to end up with such
claims persisting in the documentation even though the change in question
didn't get made and might sometimes no longer be considered desirable).
--
Hi!
On 2023-05-17T09:52:13+0200, Andreas Schwab via Gcc-patches
wrote:
> On Mai 16 2023, Vineet Gupta wrote:
>
>> Yes I was seeing similar tcl errors and such - and in my case an even
>> higher count.
>
> They are coming from commit d6654a4be3b.
I call FUD. Until you prove otherwise, of coures
Hi!
On 2023-05-24T15:13:19-0700, Vineet Gupta wrote:
> On 5/24/23 13:34, Thomas Schwinge wrote:
>> Yeah, at this point I'm not sure whether my recent changes really are
>> related/relevant here.
>>
>>> Apparently in addition to Kito's patch below, If I comment out the
>>> additional torture optio
Thanks! I will try to not forget this next time.
Am Donnerstag, dem 25.05.2023 um 21:20 +0300 schrieb Dimitar Dimitrov:
> Three recent test cases declare nested C functions, so they fail on
> targets lacking support for trampolines. Fix by adding the necessary
> filter.
>
> Committed as obvious
On Thu, 25 May 2023 at 19:32, Patrick Palka via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> On Tue, May 23, 2023 at 3:42 PM Ken Matsui via Gcc-patches
> wrote:
> >
> > Since the type_traits header is a C++11 header file, using can be used
> instead
> > of typedef. This patch provides more readabi
On Thu, May 25, 2023 at 11:31 AM Patrick Palka wrote:
>
> On Tue, May 23, 2023 at 3:42 PM Ken Matsui via Gcc-patches
> wrote:
> >
> > Since the type_traits header is a C++11 header file, using can be used
> > instead
> > of typedef. This patch provides more readability, especially for long type
On Tue, May 23, 2023 at 3:42 PM Ken Matsui via Gcc-patches
wrote:
>
> Since the type_traits header is a C++11 header file, using can be used instead
> of typedef. This patch provides more readability, especially for long type
> names.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_trai
Three recent test cases declare nested C functions, so they fail on
targets lacking support for trampolines. Fix by adding the necessary
filter.
Committed as obvious.
gcc/testsuite/ChangeLog:
* gcc.dg/nested-vla-1.c: Require effective target trampolines.
* gcc.dg/nested-vla-2.c:
On 5/25/23 02:32, Jin Ma wrote:
When the last insn1 of BB1 and the first insn2 of BB2 are fusion, insn2 will
clear all dependencies in the function chain_to_prev_insn, resulting in insn2
may mov to any BB, and the program calculation result is wrong.
gcc/ChangeLog:
* sched-deps.cc (s
Am 25.05.23 um 17:07 schrieb Richard Biener:
Am 25.05.2023 um 16:22 schrieb Georg-Johann Lay :
Am 25.05.23 um 08:35 schrieb Richard Biener:
On Wed, May 24, 2023 at 5:44 PM Georg-Johann Lay wrote:
Am 24.05.23 um 11:38 schrieb Richard Biener:
On Tue, May 23, 2023 at 2:56 PM Georg-Joha
Rewrite ix86_expand_vecop_qihi2 to expand fo 2x-wider (e.g. V16QI -> V16HImode)
instructions when available. Currently, the compiler generates following
assembly for V16QImode multiplication (-mavx2):
vpunpcklbw %xmm0, %xmm0, %xmm3
vpunpcklbw %xmm1, %xmm1, %xmm2
vpunpckhbw
Applied this patch that makes one insn more generic so it can handle
more bit positions than just 0.
Johann
--
target/82931: Make a pattern more generic to match more bit-transfers.
There is already a pattern in avr.md that matches single-bit transfers
from one register to another one, but it
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 for tree is NULL_TREE), and by being typed allows strict type checking,
> and use with function polymorphism and template instantiation.
> C++'s nullptr is pref
Many BTF type kinds refer to other types via index to the final types
list. However, the order of the final types list is not guaranteed to
remain the same for the same source program between different runs of
the compiler, making it difficult to test inter-type references.
This patch updates the
2023-05-17 Qing Zhao
gcc/c-family/ChangeLog:
PR C/108896
* c-ubsan.cc (ubsan_instrument_bounds): Use element_count attribute
information.
gcc/testsuite/ChangeLog:
PR C/108896
* gcc.dg/ubsan/flex-array-element-count-bounds.c: New test.
---
gcc/c-family/c
2023-05-17 Qing Zhao
gcc/ChangeLog:
PR C/108896
* tree-object-size.cc (addr_object_size): Use the element_count
attribute info.
* tree.cc (component_ref_has_element_count_p): New function.
(component_ref_get_element_count): New function.
* tree.h (
'element_count ("COUNT")'
The 'element_count' attribute may be attached to the flexible array
member of a structure. It indicates that the number of the
elements of the array is given by the field named "COUNT" in the
same structure as the flexible array member. GCC uses this
Hi,
This patch set introduces a new attribute "element_count" to annotate bounds
for C99 flexible array member.
A gcc bugzilla PR108896 has been created to record this task:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
A nice writeup "Bounded Flexible Arrays in C"
https://people.kernel.
On 2023-05-25, Jan Beulich wrote:
On 25.05.2023 17:16, Fangrui Song wrote:
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -32942,9 +32942,10 @@ the cache line size. @samp{compat} is the default.
@opindex mlarge-data-threshold
@item -mlarge-data-threshold=@var{threshold}
-When @option
> When testing a extension, it is often necessary for a certain program not to
> need some kind of extension, such as the bitmanip extension, to evaluate the
> performance or codesize of the extension. However, the current multilib rules
> will report an error when it is not a superset of the MULTI
Kyrylo Tkachov via Gcc-patches writes:
> Hi all,
>
> This patch expresses the intrinsics for the SRA and RSRA instructions with
> standard RTL codes rather than relying on UNSPECs.
> These instructions perform a vector shift right plus accumulate with an
> optional rounding constant addition for t
on a structure with a C99 flexible array member being nested in
another structure.
"The GCC extension accepts a structure containing an ISO C99 "flexible array
member", or a union containing such a structure (possibly recursively)
to be a member of a structure.
There are two situations:
* A
Peter, Kewen:
On Thu, 2023-05-25 at 13:28 +0800, Kewen.Lin wrote:
> on 2023/5/24 23:20, Carl Love wrote:
> > On Wed, 2023-05-24 at 13:32 +0800, Kewen.Lin wrote:
> > > on 2023/5/24 06:30, Peter Bergner wrote:
> > > > On 5/23/23 12:24 AM, Kewen.Lin wrote:
> > > > > on 2023/5/23 01:31, Carl Love wrot
On Thu, May 25, 2023 at 10:29:47AM -0400, Vladimir Makarov wrote:
>
> On 5/17/23 02:57, liuhongt wrote:
> >r14-172-g0368d169492017 replaces GENERAL_REGS with NO_REGS in cost
> >calculation when the preferred register class are not known yet.
> >It regressed powerpc PR109610 and PR109858, it looks
Hi Alex,
On Thu, May 25, 2023 at 10:55:37AM -0300, Alexandre Oliva wrote:
> On May 25, 2023, Segher Boessenkool wrote:
> > Fwiw, updating the insn counts blindly like this
>
> ... is a claim that carries a wildly incorrect and insulting underlying
> assumption:
Sorry you feel that way. I'm not
(Resend due to the previous patches didn't include the version number)
Hi,
This is the 8th version of the patch, which rebased on the latest trunk.
This is an important patch needed by Linux Kernel security project.
compared to the 7th version, the major change are:
1. update the documentation w
GCC extension accepts the case when a struct with a C99 flexible array member
is embedded into another struct or union (possibly recursively) as the last
field.
__builtin_object_size should treat such struct as flexible size.
gcc/c/ChangeLog:
PR tree-optimization/101832
* c-decl.c
On 25.05.2023 17:16, Fangrui Song wrote:
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -32942,9 +32942,10 @@ the cache line size. @samp{compat} is the default.
>
> @opindex mlarge-data-threshold
> @item -mlarge-data-threshold=@var{threshold}
> -When @option{-mcmodel=medium} is s
From: Ju-Zhe Zhong
This patch is adding SELECT_VL middle-end support
allow target have target dependent optimization in case of
length calculation.
This patch is inspired by RVV ISA and LLVM:
https://reviews.llvm.org/D99750
The SELECT_VL is same behavior as LLVM "get_vector_length" with
these f
> On May 25, 2023, at 1:41 AM, Bernhard Reutner-Fischer
> wrote:
>
> On 24 May 2023 16:09:21 CEST, Qing Zhao wrote:
>> Bernhard,
>>
>> Thanks a lot for your comments.
>>
>>> On May 19, 2023, at 7:11 PM, Bernhard Reutner-Fischer
>>> wrote:
>>>
>>> On Fri, 19 May 2023 20:49:47 +
>>> Q
When using -mcmodel=medium, large data objects larger than the
-mlarge-data-threshold threshold are placed into large data sections
(.lrodata, .ldata, .lbss and some variants). GNU ld and ld.lld 17 place
.l* sections into separate output sections. If small and medium code
model object files are m
In order to reject voodoo estimation logic with lots of magic numbers,
this patch revises the code to measure the costs of the three memset
methods based on the actual emission size of the insn sequence
corresponding to each method and choose the smallest one.
gcc/ChangeLog:
* config/xten
gcc/ChangeLog:
* config/xtensa/xtensa.md (*extzvsi-1bit_ashlsi3):
Retract excessive line folding, and correct the value of
the "length" insn attribute related to TARGET_DENSITY.
(*extzvsi-1bit_addsubx): Ditto.
---
gcc/config/xtensa/xtensa.md | 11 ++-
1 fil
This patch makes try to eliminate using temporary pseudo for
'(minus:SI (const_int) (reg:SI))' if the addition of negative constant
value can be emitted in a single machine instruction.
/* example */
int test0(int x) {
return 1 - x;
}
int test1(int x) {
return 100 - x;
> Am 25.05.2023 um 16:22 schrieb Georg-Johann Lay :
>
>
>
>> Am 25.05.23 um 08:35 schrieb Richard Biener:
>>> On Wed, May 24, 2023 at 5:44 PM Georg-Johann Lay wrote:
>>> Am 24.05.23 um 11:38 schrieb Richard Biener:
On Tue, May 23, 2023 at 2:56 PM Georg-Johann Lay wrote:
>
> P
Committed, thanks Richard.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Richard Biener via Gcc-patches
Sent: Thursday, May 25, 2023 9:06 PM
To: Richard Sandiford
Cc: juzhe.zh...@rivai.ai; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH V16] VECT: Add decrement IV iteration loop co
> Beside, V2 patch should change this:
> emit_vlmax_masked_insn (unsigned icode, int op_num, rtx *ops)
>
> change it into emit_vlmax_masked_mu_insn .
V3 is inline with these changes.
This patch implements abs2, vneg2 and vnot2 expanders
for integer vector registers and adds tests for them.
gcc/
On 5/17/23 02:57, liuhongt wrote:
r14-172-g0368d169492017 replaces GENERAL_REGS with NO_REGS in cost
calculation when the preferred register class are not known yet.
It regressed powerpc PR109610 and PR109858, it looks too aggressive to use
NO_REGS when mode can be allocated with GENERAL_REGS.
> -Original Message-
> From: Christophe Lyon
> Sent: Thursday, May 25, 2023 1:25 PM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov
> Cc: Christophe Lyon
> Subject: [PATCH 1/1] arm: merge MVE_5 and MVE_6 iterators
>
> MVE_5 and MVE_6 iterators are the same: this patch replaces MVE_6 wi
Am 25.05.23 um 08:35 schrieb Richard Biener:
On Wed, May 24, 2023 at 5:44 PM Georg-Johann Lay wrote:
Am 24.05.23 um 11:38 schrieb Richard Biener:
On Tue, May 23, 2023 at 2:56 PM Georg-Johann Lay wrote:
PR target/104327 not only affects s390 but also avr:
The avr backend pre-sets some opt
On Thu, 25 May 2023 at 16:14, Jeff Law via Gcc-patches
wrote:
>
>
>
> On 5/25/23 07:50, Richard Biener wrote:
> > On Thu, May 25, 2023 at 3:32 PM Jeff Law via Gcc-patches
> > wrote:
> >>
> >>
> >>
> >> On 5/25/23 07:01, Richard Biener via Gcc-patches wrote:
> >>> On Thu, May 25, 2023 at 2:36 PM M
On 5/25/23 07:50, Richard Biener wrote:
On Thu, May 25, 2023 at 3:32 PM Jeff Law via Gcc-patches
wrote:
On 5/25/23 07:01, Richard Biener via Gcc-patches wrote:
On Thu, May 25, 2023 at 2:36 PM Manolis Tsamis wrote:
Implementation of the new RISC-V optimization pass for memory offset
ca
On Thu, May 25, 2023 at 4:53 PM Richard Biener via Gcc-patches
wrote:
>
> On Thu, May 25, 2023 at 3:32 PM Jeff Law via Gcc-patches
> wrote:
> >
> >
> >
> > On 5/25/23 07:01, Richard Biener via Gcc-patches wrote:
> > > On Thu, May 25, 2023 at 2:36 PM Manolis Tsamis
> > > wrote:
> > >>
> > >> Imp
Hi all,
This patch annotates the complex add and mla patterns for vec-concat-zero.
Testing showed an interesting bug in our MD patterns where they were defined to
match:
(plus:VHSDF (match_operand:VHSDF 1 "register_operand" "0")
(unspec:VHSDF [(match_operand:VHSDF 2 "r
On 5/25/23 03:03, Richard Biener wrote:
On Wed, May 24, 2023 at 11:21 PM Andrew MacLeod via Gcc-patches
There is about a 1.5% slowdown to VRP to invoke and utilize the
analyzer in all 3 passes of VRP. overall compile time is 0.06% slower.
Bootstraps on x86_64-pc-linux-gnu with no regres
Hi all,
This patch implements a number of scalar data processing intrinsics from ACLE
that were requested by some users. Some of these have fast single-instruction
sequences for Armv6 and later, but even for earlier versions they can still emit
an inline sequence or a call to libgcc (and ACLE reco
On Thu, May 25, 2023 at 4:42 PM Jeff Law wrote:
>
>
>
> On 5/25/23 06:35, Manolis Tsamis wrote:
> >
> > This pass tries to optimize memory offset calculations by moving them
> > from add immediate instructions to the memory loads/stores.
> > For example it can transform this:
> >
> >addi t4,sp
On May 25, 2023, Segher Boessenkool wrote:
> Fwiw, updating the insn counts blindly like this
... is a claim that carries a wildly incorrect and insulting underlying
assumption: I've actually identified the corresponding change to the
lp64 tests, compared the effects of the codegen changes, and
On 5/24/23 22:19, juzhe.zh...@rivai.ai wrote:
>> It's highly unlikely we'll switch from the mechanisms we're using.
They're pretty deeply embedded into how all the ports are developed and
work.
We just take a look at the build file. It seems that the functions
generated by define_insn
ar
On Thu, May 25, 2023 at 3:32 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 5/25/23 07:01, Richard Biener via Gcc-patches wrote:
> > On Thu, May 25, 2023 at 2:36 PM Manolis Tsamis
> > wrote:
> >>
> >> Implementation of the new RISC-V optimization pass for memory offset
> >> calculations, document
On 5/25/23 03:22, Richard Sandiford wrote:
Jin Ma writes:
When the last insn1 of BB1 and the first insn2 of BB2 are fusion, insn2 will
clear all dependencies in the function chain_to_prev_insn, resulting in insn2
may mov to any BB, and the program calculation result is wrong.
gcc/ChangeLog:
On 5/25/23 06:35, Manolis Tsamis wrote:
This pass tries to optimize memory offset calculations by moving them
from add immediate instructions to the memory loads/stores.
For example it can transform this:
addi t4,sp,16
add t2,a6,t4
shl t3,t2,1
ld a2,0(t3)
addi a2,1
sd
On 5/25/23 06:35, Manolis Tsamis wrote:
Propagation of the stack pointer in cprop_hardreg is currenty forbidden
in all cases, due to maybe_mode_change returning NULL. Relax this
restriction and allow propagation when no mode change is requested.
gcc/ChangeLog:
* regcprop.cc (maybe_m
On Thu, May 25, 2023 at 3:25 PM Alexandre Oliva wrote:
>
> On May 25, 2023, Richard Biener wrote:
>
> > On Thu, May 25, 2023 at 1:10 PM Alexandre Oliva wrote:
> >>
> >> On May 25, 2023, Richard Biener wrote:
> >>
> >> > I mean we could do what RTL expansion would do later and do
> >> > by-piece
On 5/25/23 07:01, Richard Biener via Gcc-patches wrote:
On Thu, May 25, 2023 at 2:36 PM Manolis Tsamis wrote:
Implementation of the new RISC-V optimization pass for memory offset
calculations, documentation and testcases.
Why do fwprop or combine not what you want to do?
I think a lot of
On Thu, May 25, 2023 at 4:03 PM Richard Biener
wrote:
>
> On Thu, May 25, 2023 at 2:36 PM Manolis Tsamis
> wrote:
> >
> > Implementation of the new RISC-V optimization pass for memory offset
> > calculations, documentation and testcases.
>
> Why do fwprop or combine not what you want to do?
>
H
On May 25, 2023, Richard Biener wrote:
> On Thu, May 25, 2023 at 1:10 PM Alexandre Oliva wrote:
>>
>> On May 25, 2023, Richard Biener wrote:
>>
>> > I mean we could do what RTL expansion would do later and do
>> > by-pieces, thus emit multiple loads/stores but not n loads and then
>> > n stor
On Thu, 25 May 2023, Richard Sandiford wrote:
> This looks good to me. Just a couple of very minor cosmetic things:
>
> juzhe.zh...@rivai.ai writes:
> > @@ -753,17 +846,35 @@ vect_set_loop_condition_partial_vectors (class loop
> > *loop,
> > continue;
> > }
> >
> > - /* See
>> Yes, this is the emitted sequence, but the vsetvli mask is indeed
>> wrong. Just got lucky there. Or what else did you mean with
>> logically incorrect?
Oh, sorry. I didn't mean this patch logically incorrect.
I mean the MASK_ANY is logicall incorrect.
This patch is ok to me as long as you cha
On Thu, May 25, 2023 at 2:36 PM Manolis Tsamis wrote:
>
> Implementation of the new RISC-V optimization pass for memory offset
> calculations, documentation and testcases.
Why do fwprop or combine not what you want to do?
> gcc/ChangeLog:
>
> * config.gcc: Add riscv-fold-mem-offsets.o to
From: Pan Li
This patch would like to add new sub extension (aka ZVFHMIN) to the
-march= option. To make it simple, only the sub extension itself is
involved in this patch, and the underlying FP16 related RVV intrinsic
API depends on the TARGET_ZVFHMIN.
You can locate more information about ZVFH
Thanks Richard so much.
I have sent V17 patch for commit (fix format as you suggested).
You don't need to reply that.
I am waiting for Richi's final approval.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-05-25 20:36
To: juzhe.zhong
CC: gcc-patches; rguenther
Subject: Re: [P
From: Ju-Zhe Zhong
Fix format for Richard.
This patch is supporting decrement IV by following the flow designed by Richard:
(1) In vect_set_loop_condition_partial_vectors, for the first iteration of:
call vect_set_loop_controls_directly.
(2) vect_set_loop_controls_directly calculates "step
On 1/1/1970 8:00 AM, Thomas Koenig wrote:
Hi Lipeng,
May I know any comment or concern on this patch, thanks for your time :)
Thanks for your patience in getting this reviewed.
A few remarks / questions.
Which strategy is used in this implementation, read-preferring or
write-preferring
This looks good to me. Just a couple of very minor cosmetic things:
juzhe.zh...@rivai.ai writes:
> @@ -753,17 +846,35 @@ vect_set_loop_condition_partial_vectors (class loop
> *loop,
> continue;
> }
>
> - /* See whether zero-based IV would ever generate all-false masks
>
1 - 100 of 195 matches
Mail list logo
