On Thu, Apr 20, 2023 at 09:14:10PM -0400, Siddhesh Poyarekar wrote:
> On 2023-04-20 13:57, Siddhesh Poyarekar wrote:
> > For bounds that aren't representable, one could get error bounds from
> > libm-test-ulps data in glibc, although I reckon those won't be
> > exhaustive. From a quick peek at the
LGTM。
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-04-21 14:49
To: gcc-patches
CC: Juzhe-Zhong
Subject: [committed v2] RISC-V: Add local user vsetvl instruction elimination
[PR109547]
From: Juzhe-Zhong
This patch is to enhance optimization for auto-vectorization.
Before this patch:
Committed with an extra testcase from PR109547
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616363.html
On Fri, Apr 7, 2023 at 9:34 AM wrote:
>
> From: Juzhe-Zhong
>
> This patch is to enhance optimization for auto-vectorization.
>
> Before this patch:
>
> Loop:
> vsetvl a5,a2...
> vset
From: Juzhe-Zhong
This patch is to enhance optimization for auto-vectorization.
Before this patch:
Loop:
vsetvl a5,a2...
vsetvl zero,a5...
vle
After this patch:
Loop:
vsetvl a5,a2
vle
gcc/ChangeLog:
PR target/109547
* config/riscv/riscv-vsetvl.cc (local_eliminate_vsetvl_insn
Sorry, I didn't really commit this, it's send by accident since I give
wrong sha1
On Fri, Apr 21, 2023 at 2:47 PM Kito Cheng via Gcc-patches
wrote:
>
> ---
> gcc/common/config/riscv/riscv-common.cc | 118
> gcc/config/riscv/linux.h| 13 ++-
> 2 files cha
---
gcc/common/config/riscv/riscv-common.cc | 118
gcc/config/riscv/linux.h| 13 ++-
2 files changed, 90 insertions(+), 41 deletions(-)
diff --git a/gcc/common/config/riscv/riscv-common.cc
b/gcc/common/config/riscv/riscv-common.cc
index 309a52def75f..75b
publicKey - imtheboot1@protonmail.com - 0xAE052B51.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
The attached (gzipped) patch brings libstdc++'s PSTL implementation up to
the current upstream version.
Tested x86_64-pc-linux-gnu, specifically with TBB 2020.3 (fedora 37 +
tbb-devel).
0001-libstdc-Synchronize-PSTL-with-upstream.patch.gz
Description: application/gzip
On 2023-04-20 13:57, Siddhesh Poyarekar wrote:
For bounds that aren't representable, one could get error bounds from
libm-test-ulps data in glibc, although I reckon those won't be
exhaustive. From a quick peek at the sin/cos data, the arc target seems
to be among the worst performers at about
Hello Jeff:
On 21/04/23 2:33 am, Ajit Agarwal wrote:
> Hello Jeff:
>
> On 20/04/23 3:23 am, Jeff Law wrote:
>>
>>
>> On 4/19/23 12:00, Ajit Agarwal wrote:
>>> Hello All:
>>>
>>> This is patch-3 to improve ree pass for rs6000 target.
>>> Main functionality routines to imprve ree pass.
>>>
>>> Boot
Hello Jeff:
On 21/04/23 2:33 am, Ajit Agarwal via Gcc-patches wrote:
> Hello Jeff:
>
> On 20/04/23 3:23 am, Jeff Law wrote:
>>
>>
>> On 4/19/23 12:00, Ajit Agarwal wrote:
>>> Hello All:
>>>
>>> This is patch-3 to improve ree pass for rs6000 target.
>>> Main functionality routines to imprve ree p
Hello Jeff:
On 20/04/23 3:23 am, Jeff Law wrote:
>
>
> On 4/19/23 12:00, Ajit Agarwal wrote:
>> Hello All:
>>
>> This is patch-3 to improve ree pass for rs6000 target.
>> Main functionality routines to imprve ree pass.
>>
>> Bootstrapped and regtested on powerpc64-gnu-linux.
>>
>> Thanks & Regar
Gerald Pfeifer writes:
> Hi Arsen,
>
> On Fri, 14 Apr 2023, Arsen Arsenović wrote:
>>> Did you intentionally not implement the following part of my suggestion
>>>
>>>if [ x${MAKEINFO}x = xx ]; then
>>>:
>> > that is, allowing to override from the command-line (or crontab)?
>> (answering
Hi Kito,
I will remove the unused UNSPECs, thank you for finding them.
I removed the include of "vector-iterators.md" because "riscv.md"
already includes it and I was receiving multiple definition errors.
On 4/18/23 21:19, Kito Cheng wrote:
diff --git a/gcc/config/riscv/vector-iterators.md
Hi Arsen,
On Fri, 14 Apr 2023, Arsen Arsenović wrote:
>> Did you intentionally not implement the following part of my suggestion
>>
>>if [ x${MAKEINFO}x = xx ]; then
>>:
> > that is, allowing to override from the command-line (or crontab)?
> (answering both the questions)
>
> This := oper
Hi all.
I have noticed that in the case when we try to clear two bits through a
small constant,
and ZBS is enabled then GCC split it into two "andi" instructions.
For example for the following C code:
int foo(int a) {
return a & ~ 0x101;
}
GCC generates the following:
foo:
andi a0,
Dear all,
Fortran 2018 added a clarification that the *result* of a function
whose result *variable* has the ALLOCATABLE attribute is a *value*
that itself does not have the ALLOCATABLE attribute.
For those interested: there was a thread on the J3 mailing list
some time ago (for links see the PR)
Alejandro Colomar via Gcc-patches writes:
> Remove repeated word (typo).
>
> Signed-off-by: Alejandro Colomar
> ---
> gcc/doc/extend.texi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index fd3745c5608..cdfb25ff272 100644
>
On 2/10/23 15:41, Philipp Tomsich wrote:
When if-conversion encounters sequences using immediates, the
sequences can't trivially map back onto czero.eqz/czero.nezt (even if
benefitial) due to czero.eqz/czero.nez not having immediate forms.
This adds a splitter to rewrite opportunities for Zic
On 2023-04-20 11:52, Jakub Jelinek wrote:
Why? Unless an implementation guarantees <= 0.5ulps errors, it can be one
or more ulps off, why is an error at or near 1.0 or -1.0 error any worse
than similar errors for other values?
In a general sense, maybe not, but in the sense of breaching the bo
On 2/10/23 15:41, Philipp Tomsich wrote:
Adds a pattern to map the output of noce_try_store_flag_mask
if-conversion in the combiner onto vt.maskc; the input patterns
supported are similar to the following:
(set (reg/v/f:DI 75 [ ])
(and:DI (neg:DI (ne:DI (reg:DI 82)
On 2/10/23 15:41, Philipp Tomsich wrote:
This adds the RISC-V Zicond extension to the option parsing.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: Recognize "zicond"
as part of an architecture string.
* config/riscv/riscv-opts.h (MASK_ZICOND): Define.
> Am 20.04.2023 um 19:40 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> I've noticed I've made a typo, ifn in this function this late
> is always only IFN_CTZ or IFN_FFS, never IFN_CLZ.
>
> Due to this typo, we weren't using the originally intended
> .CTZ (X) = .POPCOUNT ((X - 1) & ~
On 3/10/23 05:40, Jin Ma via Gcc-patches wrote:
This patch adds the 'Zfa' extension for riscv, which is based on:
https://github.com/riscv/riscv-isa-manual/commit/d74d99e22d5f68832f70982d867614e2149a3bd7
latest 'Zfa' change on the master branch of the RISC-V ISA Manual as
of this writing.
Hi!
I've noticed I've made a typo, ifn in this function this late
is always only IFN_CTZ or IFN_FFS, never IFN_CLZ.
Due to this typo, we weren't using the originally intended
.CTZ (X) = .POPCOUNT ((X - 1) & ~X)
but
.CTZ (X) = PREC - .POPCOUNT (X | -X)
instead when we want to emit __builtin_ctz*/.
> Am 20.04.2023 um 19:22 schrieb Andrew MacLeod :
>
> This removes specal casing UNDEFINED ranges when we are checking to see if
> all arguments are the same and registering an equivalence.
>
> previously if there were 2 different names, and one was undefined, we ignored
> it an created an
On Thu, 20 Apr 2023 09:55:23 PDT (-0700), Vineet Gupta wrote:
ChangeLog:
* MAINTAINERS (Write After Approval): Add myself.
(Ref: <680c7bbe-5d6e-07cd-8468-247afc65e...@gmail.com>)
Signed-off-by: Vineet Gupta
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINE
On Thu, Apr 20, 2023 at 07:24:29PM +0200, Jakub Jelinek wrote:
> On Thu, Apr 20, 2023 at 12:48:57PM -0400, Marek Polacek wrote:
> > > - else if (enum_and_int_p && TREE_CODE (newdecl) != TYPE_DECL)
> > > + else if (enum_and_int_p
> > > +&& TREE_CODE (newdecl) != TYPE_DECL
> > > +/* Don't w
On Thu, Apr 20, 2023 at 12:48:57PM -0400, Marek Polacek wrote:
> > - else if (enum_and_int_p && TREE_CODE (newdecl) != TYPE_DECL)
> > + else if (enum_and_int_p
> > + && TREE_CODE (newdecl) != TYPE_DECL
> > + /* Don't warn about about acc_on_device builtin redeclaration,
>
> "built-in"
This removes specal casing UNDEFINED ranges when we are checking to see
if all arguments are the same and registering an equivalence.
previously if there were 2 different names, and one was undefined, we
ignored it an created an equivaence with the other one. as observed,
this is not a 2 way
Remove repeated word (typo).
Signed-off-by: Alejandro Colomar
---
gcc/doc/extend.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index fd3745c5608..cdfb25ff272 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -3756,7
Hi David,
On 3/24/23 18:58, David Malcolm wrote:
> On Fri, 2023-03-24 at 18:45 +0100, Alejandro Colomar wrote:
>> Hi David,
>>
>> On 3/24/23 15:53, David Malcolm wrote:
>>> On Fri, 2023-03-24 at 14:39 +0100, Alejandro Colomar via Gcc-
>>> patches
>>> wrote:
Warn about the following:
On 4/20/23 11:44, Patrick Palka wrote:
On Thu, 20 Apr 2023, Patrick Palka wrote:
1. Now that we no longer substitute the constraints of an auto, we can
get rid of the infinite recursion loop breaker during level lowering
of a constrained auto and we can also use the TEMPLATE_PARM_DESCEN
On 4/20/23 09:56, Patrick Palka wrote:
This patch makes us use a TREE_VEC instead of TREE_LIST to represent the
trailing arguments of a variadic built-in trait. These built-ins are
typically passed a simple pack expansion as the second argument, e.g.
__is_constructible(T, Ts...)
so the mai
On 4/20/23 09:56, Patrick Palka wrote:
If we have a TREE_VEC of types that we want to strip of typedefs, we
unintuitively need to call strip_typedefs_expr instead of strip_typedefs
since only strip_typedefs_expr handles TREE_VEC, and it also dispatches
to strip_typedefs when given a type. But th
ChangeLog:
* MAINTAINERS (Write After Approval): Add myself.
(Ref: <680c7bbe-5d6e-07cd-8468-247afc65e...@gmail.com>)
Signed-off-by: Vineet Gupta
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index cebf45d49e56..5f25617212a5 100644
--- a/M
On 1/17/23 15:59, Vineet Gupta wrote:
This could be useful for library writers who want to write code variants
for fast vs. slow unaligned accesses.
We distinguish explicit -mstrict-align (1) vs. slow_unaligned_access
cpu tune param (2) for even more code divesity.
gcc/ChangeLog:
*
On Wed, Apr 19, 2023 at 11:02:53AM +0200, Jakub Jelinek wrote:
> Hi!
>
> The new -Wenum-int-mismatch warning triggers with -Wsystem-headers in
> , for obvious reasons the builtin acc_on_device uses int
> type argument rather than enum which isn't defined yet when the builtin
> is created, while th
On 12/2/22 00:26, Eric Gallager via Gcc-patches wrote:
I tried turning -Wnarrowing back on earlier this year, but
unfortunately it didn't work due to triggering a bunch of new errors.
This patch silences at least some of them, but there will still be
more left even after applying it. (When com
"Andre Vieira (lists)" writes:
> On 20/04/2023 15:51, Richard Sandiford wrote:
>> "Andre Vieira (lists)" writes:
>>> Hi all,
>>>
>>> This is a series of patches/RFCs to implement support in GCC to be able
>>> to target AArch64's libmvec functions that will be/are being added to glibc.
>>> We have
On Thu, Apr 20, 2023 at 04:22:50PM +0100, Andre Vieira (lists) wrote:
> > I don't see a good reason for dropping the extension("scalable").
> > The problem is that since the base spec requires a simdlen clause,
> > GCC should in general raise an error if simdlen is omitted.
> Where can you find thi
On Thu, Apr 20, 2023 at 11:22:24AM -0400, Siddhesh Poyarekar wrote:
> On 2023-04-20 10:02, Jakub Jelinek wrote:
> > On x86_64-linux with glibc 2.35, I see
> > for i in FLOAT DOUBLE LDOUBLE FLOAT128; do for j in TONEAREST UPWARD
> > DOWNWARD TOWARDZERO; do gcc -D$i -DROUND=FE_$j -g -O1 -o /tmp/sinc
On Thu, 20 Apr 2023, Patrick Palka wrote:
> 1. Now that we no longer substitute the constraints of an auto, we can
>get rid of the infinite recursion loop breaker during level lowering
>of a constrained auto and we can also use the TEMPLATE_PARM_DESCENDANTS
>cache in this case.
> 2. Do
1. Now that we no longer substitute the constraints of an auto, we can
get rid of the infinite recursion loop breaker during level lowering
of a constrained auto and we can also use the TEMPLATE_PARM_DESCENDANTS
cache in this case.
2. Don't bother recursing when level lowering a cv-qualifi
On 20/04/2023 15:51, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
Hi all,
This is a series of patches/RFCs to implement support in GCC to be able
to target AArch64's libmvec functions that will be/are being added to glibc.
We have chosen to use the omp pragma '#pragma omp declare
On 2023-04-20 10:02, Jakub Jelinek wrote:
On x86_64-linux with glibc 2.35, I see
for i in FLOAT DOUBLE LDOUBLE FLOAT128; do for j in TONEAREST UPWARD DOWNWARD
TOWARDZERO; do gcc -D$i -DROUND=FE_$j -g -O1 -o /tmp/sincos{,.c} -lm;
/tmp/sincos || echo $i $j; done; done
Aborted (core dumped)
FLOAT
"Andre Vieira (lists)" writes:
> Hi,
>
> This patch replaces the uses of simd_clone_subparts with
> TYPE_VECTOR_SUBPARTS and removes the definition of the first.
>
> gcc/ChangeLog:
>
> * omp-sind-clone.cc (simd_clone_subparts): Remove.
> (simd_clone_init_simd_arrays): Replace si
The following patch fixes test failure of 20030222-1.c on moxie port.
But the problem can occur on other targets. The patch actually
implements the old reload approach for the test case.
The patch was successfully tested and bootstrapped on x86-64, aarch64,
and ppc64le.
commit 51703ac3c722
gcc/ChangeLog:
* config/arm/arm.cc (thumb1_legitimate_address_p):
Use VIRTUAL_REGISTER_P predicate.
(arm_eliminable_register): Ditto.
* config/avr/avr.md (push_1): Ditto.
* config/bfin/predicates.md (register_no_elim_operand): Ditto.
* config/h8300/predicates.md (register_n
Introduce extract_operator predicate to handle both, zero-extract and
sign-extract extract operations with expressions like:
(subreg:QI
(zero_extract:SWI248
(match_operand 1 "int248_register_operand" "0")
(const_int 8)
(const_int 8)) 0)
As shown in the testcase, this wil
"Andre Vieira (lists)" writes:
> Hi all,
>
> This is a series of patches/RFCs to implement support in GCC to be able
> to target AArch64's libmvec functions that will be/are being added to glibc.
> We have chosen to use the omp pragma '#pragma omp declare variant ...'
> with a simd construct as
On Thu, Apr 20, 2023 at 04:02:02PM +0200, Jakub Jelinek via Gcc-patches wrote:
> So, I wrote following test.
Slightly adjusted to see more info:
x86_64-linux glibc 2.35:
for i in FLOAT DOUBLE LDOUBLE FLOAT128; do for j in TONEAREST UPWARD DOWNWARD
TOWARDZERO; do gcc -D$i -DROUND=FE_$j -g -O1 -o
Hi,
Is this patch ready for GCC14?
Thanks.
Qing
Begin forwarded message:
From: Qing Zhao via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>>
Subject: Fwd: [V6][PATCH 2/2] Update documentation to clarify a GCC extension
Date: April 11, 2023 at 9:38:29 AM EDT
To: Joseph Myers mailto:jos...@codesou
Hi,
Is this patch ready for GCC14?
Thanks.
Qing
Begin forwarded message:
From: Qing Zhao via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>>
Subject: Fwd: [V6][PATCH 1/2] Handle component_ref to a structre/union field
including flexible array member [PR101832]
Date: April 11, 2023 at 9:37:18 AM
This is the 3rd ping for the 6th version of the patches.
Now, GCC14 is open. Is it ready to commit these patches to GCC14?
Kees has tested this version of the patch with Linux kernel, and everything is
good, and relsolved many false
positives for bounds checking.
Note for the review history of
On Thu, Apr 20, 2023 at 09:17:10AM -0400, Siddhesh Poyarekar wrote:
> On 2023-04-20 08:59, Jakub Jelinek via Gcc-patches wrote:
> > > +r.set (type, dconstm1, dconst1);
> >
> > See above, are we sure we can use [-1., 1.] range safely, or should that be
> > [-1.-Nulps, 1.+Nulps] for some kind of
Hi Kito,
There is one patch reviewed already and I suppose it will be ok after GCC 14
open. Could you please help to double check about it?
Pann
-Original Message-
From: Gcc-patches On Behalf
Of Li, Pan2 via Gcc-patches
Sent: Wednesday, March 29, 2023 6:39 PM
To: juzhe.zh...@rivai.ai;
This patch makes us use a TREE_VEC instead of TREE_LIST to represent the
trailing arguments of a variadic built-in trait. These built-ins are
typically passed a simple pack expansion as the second argument, e.g.
__is_constructible(T, Ts...)
so the main benefit of this representation change me
If we have a TREE_VEC of types that we want to strip of typedefs, we
unintuitively need to call strip_typedefs_expr instead of strip_typedefs
since only strip_typedefs_expr handles TREE_VEC, and it also dispatches
to strip_typedefs when given a type. But this seems backwards: arguably
strip_typede
Committed to trunk, thanks :)
On Tue, Apr 18, 2023 at 9:50 PM Jeff Law wrote:
>
>
>
> On 3/13/23 02:19, juzhe.zh...@rivai.ai wrote:
> > From: Ju-Zhe Zhong
> >
> > Co-authored-by: kito-cheng
> > Co-authored-by: kito-cheng
> >
> > Consider this case:
> > void f19 (void *base,void *base2,void *ou
I've committed this to the devel/omp/gcc-12 branch.
The patch fixes a concurrency issue where the spin-locks didn't work
well if many GPU threads tried to free low-latency memory all at once.
Adding a short sleep instruction is enough for the hardware thread to
yield and allow another to proc
In newer ISA spec, F will implied zicsr, add that into -march option to
prevent different test result on different default -misa-spec version.
gcc/testsuite/
* gcc.target/riscv/arch-19.c: Add -misa-spec.
---
gcc/testsuite/gcc.target/riscv/arch-19.c | 4 ++--
1 file changed, 2 insertions(
GCC will complaint if target ABI isn't have corresponding multi-lib on
glibc toolchain, use stdint-gcc.h to suppress that.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/simplify_ior_optimization.c: Use stdint-gcc.h
rather than stdint.h
---
gcc/testsuite/gcc.target/riscv/simplify_io
Rebased all three patches and made some small changes to the second one:
- removed sub and abd optabs from commutative_optab_p, I suspect this
was a copy paste mistake,
- removed what I believe to be a superfluous switch case in vectorizable
conversion, the one that was here:
+ if (code.is_fn_
Committed, thanks!
On Wed, Apr 19, 2023 at 6:42 PM wrote:
>
> From: Ju-Zhe Zhong
>
> Testcase coming from Kito.
>
> Co-authored-by: kito-cheng
> Co-authored-by: kito-cheng
>
> PR 109535
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vsetvl.cc (count_regno_occurrences): New
> func
On 2023-04-20 08:59, Jakub Jelinek via Gcc-patches wrote:
+r.set (type, dconstm1, dconst1);
See above, are we sure we can use [-1., 1.] range safely, or should that be
[-1.-Nulps, 1.+Nulps] for some kind of expected worse error margin of the
implementation? And ditto for -frounding-math, s
Hi Bernhard,
Thanks for your questions and suggestions.
The rwlock could allow multiple threads to have concurrent read-only
access to the cache/unit list, only a single writer is allowed.
Write lock will not be acquired until all read lock are released.
And I didn't change the mutex scope when
On Tue, Apr 18, 2023 at 03:12:50PM +0200, Aldy Hernandez wrote:
> [I don't know why I keep poking at floats. I must really like the pain.
> Jakub, are you OK with this patch for trunk?]
Thanks for working on this. Though expectedly here we are running
again into the discussions we had in Novembe
On Wed, Apr 19, 2023 at 03:15:51PM +0800, liuhongt wrote:
ChangeLog nits have been already reported earlier.
> --- a/gcc/config/i386/i386-c.cc
> +++ b/gcc/config/i386/i386-c.cc
> @@ -817,6 +817,43 @@ ix86_target_macros (void)
>if (!TARGET_80387)
> cpp_define (parse_in, "_SOFT_FLOAT");
>
The hardfp division patch exposed a flaw in the ldexp pattern at -O0;
the compiler was trying to use out-of-range immediates on VOP3
instruction encodings.
This patch changes the constraints appropriately, and also takes the
opportunity to combine the two patterns into one using the newly
ava
Recent patches have enabled new capabilities on AMD GCN, but not all the
testsuite features were enabled. The hardfp divide patch actually had an
test regression because the expected results were too conservative.
This patch corrects both issues.
Andrewamdgcn: update target-supports.exp
The b
On Thu, 20 Apr 2023, juzhe.zh...@rivai.ai wrote:
> Thanks Richards (Sandiford && Biener).
> I have a technique question:
> In case of support variable IVs for memory address calculation, is it right I
> should make output of WHILE_LEN
> visible in tree-ssa-loop-ivopts.cc ? Since the address calcu
The following avoids registering two-way equivalences from PHIs when
UNDEFINED arguments are involved.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
As noted this causes missed optimizations for the cases where
we have unreachable edges rather than UNDEFINED ranges.
OK for trunk / branch?
On Wed, Apr 19, 2023 at 6:38 PM wrote:
>
> From: Ju-Zhe Zhong
>
> This patch is adding 2 compile option for RVV auto-vectorization.
> 1. -param=riscv-autovec-preference=
>This option is to specify the auto-vectorization approach for RVV.
>Currently, we only support scalable and fixed-vlma
Thanks Richards (Sandiford && Biener).
I have a technique question:
In case of support variable IVs for memory address calculation, is it right I
should make output of WHILE_LEN
visible in tree-ssa-loop-ivopts.cc ? Since the address calculation is not in
the loop control handling function.
Thank
Hi Robin:
Share with you more context that I've discussed with Ju-Zhe, and look
for comments from you :)
There is 3 different auto vectorization flavor:
- VLA
- VLS fixed-vlmax (Name TBD)
- (Traditional) VLS
I think I don't need to explain too much on VLA.
So let we focus on second and third:
V
---
htdocs/gcc-13/changes.html | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index f6941534..4515a6af 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -636,7
writes:
> Yes, like kito said.
> We won't enable VNx1DImode in auto-vectorization so it's meaningless to fix
> it here.
> We dynamic adjust the minimum vector-length for different '-march' according
> to RVV ISA specification.
> So we strongly suggest that we should drop this fix.
I think the p
Richard Biener writes:
> On Thu, 20 Apr 2023, Richard Sandiford wrote:
>
>> "juzhe.zh...@rivai.ai" writes:
>> > OK. Thanks Richard.
>> > So let me conclude:
>> > 1. Community agree that I should support variable IV in the middle-end.
>> > 2. We can keep WHILE_LEN pattern when "not only final iter
On Thu, 20 Apr 2023, Richard Sandiford wrote:
> "juzhe.zh...@rivai.ai" writes:
> > OK. Thanks Richard.
> > So let me conclude:
> > 1. Community agree that I should support variable IV in the middle-end.
> > 2. We can keep WHILE_LEN pattern when "not only final iteration is partial".
> > And I
Ahhh. These compile options are not finalized.
I just ask kito provide me some compile option that I can specify LMUL &&
auto-vectorization mode && vector-length (scalable or fixed-length)
in order to have chances test auto-vectorizaiton fully for example: fully
testing LMUL = 1/2/4/8 auto-vecto
> Can you give more comments about Robin's opinion that he want to change into
> "fixed" vs "varying" or "fixed vector size" vs "dynamic vector size" ?
It's not necessary to decide on this now as --params are not supposed
to be stable and can be changed quickly. I was just curious if this had
alr
Ahhh. Thanks kito.
Can you give more comments about Robin's opinion that he want to change into
"fixed" vs "varying" or "fixed vector size" vs "dynamic vector size" ?
I am Ok with any of them.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-04-20 17:31
To: juzhe.zh...@rivai.ai
CC: Robin D
On Thu, Apr 20, 2023 at 5:07 PM juzhe.zh...@rivai.ai
wrote:
>
> >> With --param=riscv-autovec-preference=fixed-vlmax, however, the output is
> >> reasonable. BTW please use --param instead of -param in the description to
> >> avoid confusion.
> >>Now the patches don't explicitly note that they on
Hi, kito. Can you give more comments for us in case of compile options?
I think I should fix this patch after we have done all discussions of compile
option
of choosing vector-length && LMUL && auto-vectorization mode (VLA/VLS).
I just received Richard Sandiford comments of "WHILE_LEN" pattern.
O
The following removes unused CFG order computes from
rest_of_handle_df_initialize. The CFG orders are computed from df_analyze ().
This also removes code duplication that would have to be kept in sync.
Bootstrapped and tested on x86_64-unknown-linux-gnu for all languages,
pushed.
* df-co
"juzhe.zh...@rivai.ai" writes:
> OK. Thanks Richard.
> So let me conclude:
> 1. Community agree that I should support variable IV in the middle-end.
> 2. We can keep WHILE_LEN pattern when "not only final iteration is partial".
> And I should describe it more clearly in the doc.
>
> I should d
On Thu, 20 Apr 2023, Jakub Jelinek wrote:
> Hi!
>
> The following patch allows to vectorize __builtin_ffs*/.FFS even if
> we just have vector .CTZ support, or __builtin_ffs*/.FFS/__builtin_ctz*/.CTZ
> if we just have vector .CLZ or .POPCOUNT support.
> It uses various expansions from Hacker's Del
OK. Thanks Richard.
So let me conclude:
1. Community agree that I should support variable IV in the middle-end.
2. We can keep WHILE_LEN pattern when "not only final iteration is partial".
And I should describe it more clearly in the doc.
I should do these 2 things in the later update patch.
I
"juzhe.zh...@rivai.ai" writes:
> Thanks Richard reminding me. I originally think community does not allow me
> support variable amount IV and let me do this in RISC-V backend.
No, I think that part should and needs to be done in the middle-end,
since if the initial IVs are incorrect, it's very d
>> With --param=riscv-autovec-preference=fixed-vlmax, however, the output is
>> reasonable. BTW please use --param instead of -param in the description to
>> avoid confusion.
>>Now the patches don't explicitly note that they only work for certain marchs,
>>configurations or so but they certainly s
> $ riscv64-unknown-linux-gnu-gcc
> --param=riscv-autovec-preference=fixed-vlmax
> gcc/testsuite/gcc.target/riscv/rvv/base/spill-10.c -O2 -march=rv64gcv
> -S
> ../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/testsuite/gcc.target/riscv/rvv/base/spill-10.c:
> In function 'stach_check_alloca_1':
> ../riscv
Thanks Richard reminding me. I originally think community does not allow me
support variable amount IV and let me do this in RISC-V backend.
It seems that I can do that in middle-end. Thank you so much. I will update the
patch. Really appreciate it!
juzhe.zh...@rivai.ai
From: Richard Sandifo
钟居哲 writes:
> Hi, Richards.
> Since GCC 14 is open and this patch has been boostraped && tested on X86.
> Is this patch supporting variable IV OK for the trunk ?
Doesn't the patch need updating based on the previous discussion?
I thought the outcome was that WHILE_LEN isn't a simple MIN operation
On Wed, Apr 19, 2023 at 11:20:09AM -0400, Jason Merrill wrote:
> * g++.dg/ext/int128-8.C: New test.
The testcase needs to be restricted to int128 effective targets,
it expectedly fails on i386 and other 32-bit targets.
Tested using
GXX_TESTSUITE_STDS=98,11,14,17,20,2b make check-g++
RUNTES
Hi,
on 2023/4/20 14:04, HAO CHEN GUI wrote:
> Hi,
> This patch xfails a float128 comparison test case on powerpc64
> that fails due to a longstanding issue with floating-point
> compares.
>
> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684 for more
> information.
>
> The patch passe
Hi,
on 2023/4/20 14:04, HAO CHEN GUI wrote:
> Hi,
> This patch adds ppc_cpu_supports_hw into explicit name checking in
> proc is-effective-target-keyword. So ppc_cpu_supports_hw can be used
> as a target selector in test directives. It's required by patch2 of
> this issue.
OK for trunk, thanks!
Hi!
The following patch allows to vectorize __builtin_ffs*/.FFS even if
we just have vector .CTZ support, or __builtin_ffs*/.FFS/__builtin_ctz*/.CTZ
if we just have vector .CLZ or .POPCOUNT support.
It uses various expansions from Hacker's Delight book as well as GCC's
expansion, in particular:
.C
Am Dienstag, dem 04.04.2023 um 19:31 -0600 schrieb Jeff Law:
>
> On 4/3/23 13:34, Martin Uecker via Gcc-patches wrote:
> >
> >
> > With the relatively new warnings (11..) affecting VLA bounds,
> > I now get a lot of false positives with -Wall. In general, I find
> > the new warnings very useful,
99 matches
Mail list logo
