Hi, For the first piece of code ,I tried:
unsigned int nitems_per_iter
= dest_rgm->max_nscalars_per_iter * dest_rgm->factor;
step = gimple_build (seq, MULT_EXPR, iv_type, step,
build_int_cst (iv_type, nitems_per_iter));
Then optimized IR:
loop_len_34 = MIN_EXPR ;
_
On Wed, 24 May 2023 at 16:06, Matthias Kretz via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> OK for master and backports? (also a long-standing bug that didn't surface
> until the new constexpr test was added)
>
OK for all
>
> tested on powerpc64le-linux-gnu
>
> - 8< ---
> Am 24.05.2023 um 16:21 schrieb Alexander Monakov :
>
>
>> On Wed, 24 May 2023, Richard Biener wrote:
>>> On Wed, May 24, 2023 at 2:54 PM Alexander Monakov via Gcc-patches
>>> wrote:
>>> Explicitly say that bitwise shifts for narrow types work similar to
>>> element-wise C shifts with integ
On 5/24/23 10:20 AM, Carl Love wrote:
> Extending the builtin to pre Power 9 is straight forward and I agree
> would make good sense to do.
>
> I am a bit concerned on how to extend __builtin_set_fpscr_rn to add the
> new functionality. Peter suggests overloading the builtin to either
> return vo
Hi, Richard. After I fix codes, now IR is correct I think:
loop_len_34 = MIN_EXPR ;
_74 = loop_len_34 * 2;
loop_len_48 = MIN_EXPR <_74, 4>;
_75 = _74 - loop_len_48;
loop_len_49 = MIN_EXPR <_75, 4>;
_76 = _75 - loop_len_49;
loop_len_50 = MIN_EXPR <_76, 4>;
loop_len_51 = _76 - loop_len
On Wed, May 24, 2023 at 2:03 AM Richard Biener via Gcc-patches
wrote:
>
> On Wed, May 24, 2023 at 1:16 AM Andrew Pinski via Gcc-patches
> wrote:
> >
> > While trying to understand how to use the ! operand for match
> > patterns, I noticed that the debug dumps would print out applying
> > a patter
Hi, Joseph,
I modified the gcc/doc/extend.texi per your suggestion as following:
Let me know if you have further comment and suggestion on this patch.
I will send out the V8 of the patch after some testing.
Thanks.
Qing.
diff --git a/gcc/doc/exten
Hello All:
This patch improves code sinking pass to sink statements before call to reduce
register pressure.
Review comments are incorporated.
For example :
void bar();
int j;
void foo(int a, int b, int c, int d, int e, int f)
{
int l;
l = a + b + c + d +e + f;
if (a != 5)
{
bar(
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 preferred over NULL and 0 for pointer types that don't
have a defined
+CC Thomas and Maciej
On 5/22/23 20:52, Vineet Gupta wrote:
On 5/22/23 02:17, Kito Cheng wrote:
Ooops, seems still some issue around here,
Yep still 5000 fails :-(
but I found something might
related this issue:
https://github.com/gcc-mirror/gcc/commit/d6654a4be3ba44c0d57be7c8a51d76d9721
On Wed, 24 May 2023, Richard Biener via Gcc-patches wrote:
> I’d have to check the ISAs what they actually do here - it of course depends
> on RTL semantics as well but as you say those are not strictly defined here
> either.
Plus, we can add the following executable test to the testsuite:
#in
gcc/ChangeLog:
* value-range.h (vrange::kind): Remove.
---
gcc/value-range.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/gcc/value-range.h b/gcc/value-range.h
index 936eb175062..b8cc2a0e76a 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@ -100,9 +100,6 @@ public:
boo
Middle-end folks: any thoughts about how best to make the change described in
the last paragraph below?
Library folks: any thoughts on the changes to __cxa_call_terminate?
-- 8< --
[except.handle]/7 says that when we enter std::terminate due to a throw,
that is considered an active handler. We
Dear all,
the attached almost obvious patch fixes an ICE on invalid that may
occur when we attempt to simplify an initialization expression with
SIZE for an out-of-range DIM argument. Returning gfc_bad_expr
allows for a more graceful error recovery.
Regtested on x86_64-pc-linux-gnu. OK for main
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? And if read-preferring is used, is there
a dan
Le 24/05/2023 à 21:16, Harald Anlauf via Fortran a écrit :
Dear all,
the attached almost obvious patch fixes an ICE on invalid that may
occur when we attempt to simplify an initialization expression with
SIZE for an out-of-range DIM argument. Returning gfc_bad_expr
allows for a more graceful er
Le 21/05/2023 à 22:48, Harald Anlauf via Fortran a écrit :
Dear all,
checking and simplification of the RESHAPE intrinsic could fail in
various ways for sufficiently complicated arguments, like array
constructors. Debugging revealed that in these cases we determined
that the array arguments wer
On Wed, 24 May 2023 at 15:40, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Mon, 22 May 2023 at 14:18, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > Hi Richard,
> >> > Thanks for the suggestions. Does the attached patch look OK ?
> >> > Boostrap+tes
Prathamesh Kulkarni writes:
> On Wed, 24 May 2023 at 15:40, Richard Sandiford
> wrote:
>>
>> Prathamesh Kulkarni writes:
>> > On Mon, 22 May 2023 at 14:18, Richard Sandiford
>> > wrote:
>> >>
>> >> Prathamesh Kulkarni writes:
>> >> > Hi Richard,
>> >> > Thanks for the suggestions. Does the att
I'll look at the samples tomorrow, but just to address one thing:
钟居哲 writes:
>>> What gives the best code in these cases? Is emitting a multiplication
>>> better? Or is using a new IV better?
> Could you give me more detail information about "new refresh IV" approach.
> I'd like to try that.
On Wed, May 24, 2023 at 5:00 AM Jonathan Wakely via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Wed, 24 May 2023 at 09:41, Xi Ruoyao wrote:
>
> > Wang Lei raised some concerns about Itanium C++ ABI, so let's ask a C++
> > expert here...
> >
> > Jonathan: AFAIK the standard and the Itanium
Hi!
On 2023-05-24T11:18:35-0700, Vineet Gupta wrote:
> On 5/22/23 20:52, Vineet Gupta wrote:
>> On 5/22/23 02:17, Kito Cheng wrote:
>>> Ooops, seems still some issue around here,
>>
>> Yep still 5000 fails :-(
>>
>>> but I found something might
>>> related this issue:
>>>
>>> https://github.com
On Tue, 2023-05-23 at 09:34 +, Christophe Lyon wrote:
> The gcc.dg/analyzer/data-model-4.c and
> gcc.dg/analyzer/torture/conftest-1.c fail with recent glibc headers
> and succeed with older headers.
>
> The new error message is:
> warning: use of possibly-NULL 'f' where non-null expected [CWE-
I originally implemented the lazy ssa cache by inheriting from an
ssa_cache in protected mode and providing the required routines. This
makes it a little awkward to do various things, and they also become not
quite as interchangeable as I'd like. Making the routines virtual and
using proper i
This tweaks someof the fold_stmt routines and helpers.. in particular
the ones which you provide a vector of ranges to to satisfy any ssa-names.
Previously, once the vector was depleted, any remaining values were
picked up from the default get_global_range_query() query. It is useful
to be abl
This patch provide the framework for a gimple-range phi analyzer.
Currently, the primary purpose is to give better initial values for
members of a "phi group"
a PHI group is defined as a a group of PHI nodes whose arguments are all
either members of the same PHI group, or one of 2 other valu
By having an ssa_cache inherit from a range_query, and then providing a
range_of_expr routine which returns the current global value, we open up
the possibility of folding statements and doing other interesting things
with an ssa-cache.
In particular, you can now call fold_range() with an ssa
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 options, failures go down drastically.
Meaning that *all* those ERRORs dis
On 5/24/23 15:13, Vineet Gupta wrote:
PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects (test for excess errors)
PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects scan-assembler-times mul\t 1
PASS: gcc.target/riscv/z
On Wed, 24 May 2023 16:12:20 PDT (-0700), Vineet Gupta wrote:
On 5/24/23 15:13, Vineet Gupta wrote:
PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects (test for excess errors)
PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-obj
`This patch tries to prevent generating unnecessary sign extension
after *w instructions like "addiw" or "divw".
The main idea of it is to add SUBREG_PROMOTED fields during expanding.
I have tested on SPEC2017 there is no regression.
Only gcc.dg/pr30957-1.c test failed.
To solve that I did some c
On 5/24/23 17:12, Vineet Gupta wrote:
On 5/24/23 15:13, Vineet Gupta wrote:
PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects (test for excess errors)
PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects scan-assembl
From: Lili Cui
Make some changes in reassoc pass to make it more friendly to fma pass later.
Using FMA instead of mult + add reduces register pressure and insruction
retired.
There are mainly two changes
1. Put no-mult ops and mult ops alternately at the end of the queue, which is
conducive to g
> > +rewrite_expr_tree_parallel (gassign *stmt, int width, bool has_fma,
> > +const vec
> > +&ops)
> > {
> >enum tree_code opcode = gimple_assign_rhs_code (stmt);
> >int op_num = ops.length ();
> > @@ -5483,10 +5494,11 @@ rewrite_expr_tree_parallel (
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 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
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 wordings based on Joseph's suggestions.
2. change the name of the new ma
在 2023/5/25 上午4:15, Jason Merrill 写道:
On Wed, May 24, 2023 at 5:00 AM Jonathan Wakely via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>> wrote:
On Wed, 24 May 2023 at 09:41, Xi Ruoyao wrote:
> Wang Lei raised some concerns about Itanium C++ ABI, so let's
ask a C++
> expert her
On 2023/5/25 10:46, Lulu Cheng wrote:
在 2023/5/25 上午4:15, Jason Merrill 写道:
On Wed, May 24, 2023 at 5:00 AM Jonathan Wakely via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>> wrote:
On Wed, 24 May 2023 at 09:41, Xi Ruoyao wrote:
> Wang Lei raised some concerns about Itanium C++ ABI,
Hi all,
This patch aims to fix incorrect intrinsic signature for
_mm{512|256|}_s{lli|rai|rli}_epi*. And it has been tested on
x86_64-pc-linux-gnu. OK for trunk?
BRs,
Lin
gcc/ChangeLog:
PR target/109173
PR target/109174
* config/i386/avx512bwintrin.h (_mm512_srli_epi16)
From: Ju-Zhe Zhong
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" as in your patch.
If rg
Hi, Richard.
After several tries with your testcases (I already added into V15 patch).
I think "using a new IV" would be better than "multiplication"
Now:
loop_len_34 = MIN_EXPR ;
_74 = MIN_EXPR ; --> multiplication approach will changed
into _74 = loop_len_34 * 2;
loop_len_48 = MIN
From: Pan Li
This patch would like to optimize the VLS vector initialization like
repeating sequence. From the vslide1down to the vmerge with a simple
cost model, aka every instruction only has 1 cost.
Given code with -march=rv64gcv_zvl256b --param
riscv-autovec-preference=fixed-vlmax
typedef i
Hi Kito,
Update the PATCH v6 with refactored framework as below, thanks for comments.
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619536.html
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Wednesday, May 17, 2023 11:52 AM
To: juzhe.zh...@
* machmode.h (VECTOR_BOOL_MODE_P): New macro.
--- a/gcc/machmode.h
+++ b/gcc/machmode.h
@@ -134,6 +134,10 @@ extern const unsigned char mode_class[NUM_MACHINE_MODES];
|| GET_MODE_CLASS (MODE) == MODE_VECTOR_ACCUM \
|| GET_MODE_CLASS (MODE) == MODE_VECTOR_UACCUM)
+/* Nonzero if MODE
Oops, forget to remove it in previous version, will wait a while and update
them together.
Pan
From: juzhe.zh...@rivai.ai
Sent: Thursday, May 25, 2023 11:14 AM
To: Li, Pan2 ; gcc-patches
Cc: Kito.cheng ; Li, Pan2 ; Wang,
Yanzhang
Subject: Re: [PATCH v6] RISC-V: Using merge approach to optimi
On Thu, May 25, 2023 at 10:55 AM Hu, Lin1 via Gcc-patches
wrote:
>
> Hi all,
>
> This patch aims to fix incorrect intrinsic signature for
> _mm{512|256|}_s{lli|rai|rli}_epi*. And it has been tested on
> x86_64-pc-linux-gnu. OK for trunk?
>
> BRs,
> Lin
>
> gcc/ChangeLog:
>
> PR target/10
在 2023/5/25 上午10:52, WANG Xuerui 写道:
On 2023/5/25 10:46, Lulu Cheng wrote:
在 2023/5/25 上午4:15, Jason Merrill 写道:
On Wed, May 24, 2023 at 5:00 AM Jonathan Wakely via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>> wrote:
On Wed, 24 May 2023 at 09:41, Xi Ruoyao wrote:
> Wang Lei rais
On 5/24/23 17:13, Palmer Dabbelt wrote:
On Wed, 24 May 2023 16:12:20 PDT (-0700), Vineet Gupta wrote:
[ ... big snip ... ]
Never mind. Looks like I found the issue - with just trial and error and
no idea of how this stuff works.
The torture-{init,finish} needs to be in riscv.exp not rvv.e
segment intrinsics are really huge amount.
Even though I have tried to optimized them, still we have the issues..
How about LLVM? Can kito help with this issue?
LLVM has already support full intrinsics for a long time and no issues.
Thanks.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 202
Besides, we don't have compilation issues in crossing-compiling (with segment
intrinsics).
But I do agree we need to address such issue.
As far as I known, GCC compile insn-emit in single thread single core.
Can we multi-thread && multi-core to compile it to speed up the compilation?
Thanks.
j
Jojo has a patch to try to split those things that should help this,
but seems not landed.
https://patchwork.ozlabs.org/project/gcc/patch/20201104015315.81416-1-jiejie_r...@c-sky.com/
> How about LLVM? Can kito help with this issue?
> LLVM has already supported full intrinsics for a long time an
>> IIRC LLVM is using the table driven mechanism, so it's less impact on the
>> compilation time when the instruction becomes more and more.
Oh, I see. Could you share more details ?
Maybe we can support this in GCC.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-05-25 11:53
To: juzhe.zh...@
LGTM, thanks :)
On Wed, May 24, 2023 at 7:26 PM wrote:
>
> From: Juzhe-Zhong
>
> According to RVV ISA:
> The conversions use the dynamic rounding mode in frm, except for the rtz
> variants, which round towards zero.
>
> So rtz conversion patterns should not have FRM dependency.
>
> We can't sup
On 5/24/23 21:53, Kito Cheng wrote:
Jojo has a patch to try to split those things that should help this,
but seems not landed.
https://patchwork.ozlabs.org/project/gcc/patch/20201104015315.81416-1-jiejie_r...@c-sky.com/
Is JoJo still active? I haven't heard from JoJo in many months, perhaps
On 5/24/23 21:54, juzhe.zh...@rivai.ai wrote:
>> IIRC LLVM is using the table driven mechanism, so it's less impact
on the
compilation time when the instruction becomes more and more.
Oh, I see. Could you share more details ?
Maybe we can support this in GCC.
It's highly unlikely we'll swit
Yeah, JoJo still working on toolchain stuff, but just not active on upstream GCC
cc. jojo
On Thu, May 25, 2023 at 12:06 PM Jeff Law wrote:
>
>
>
> On 5/24/23 21:53, Kito Cheng wrote:
> > Jojo has a patch to try to split those things that should help this,
> > but seems not landed.
> >
> > https:
>> 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
are so many. Do we have the chance optimize it?
I be
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 wrote:
> The builtins were requested for use in GLibC. As of version
> 2.31 th
We're ICEing when trying to hash a known NAN. This is unnoticeable
because the only user would be IPA, and even so, it currently doesn't
handle floats. However, handling floats is a flip of a switch, so
it's best to handle them already.
gcc/ChangeLog:
* value-range.cc (add_vrange): Hand
Generalize frange::set_nan() to take a nan_state and make current
set_nan() methods syntactic sugar.
This is in preparation for better streaming of NANs for LTO/IPA.
gcc/ChangeLog:
* value-range.h (frange::set_nan): New.
---
gcc/value-range.h | 32 +---
1 fil
frange::set() is confusing in that we can set a NAN by specifying a
bound of +-NAN, even though we tecnically disallow NANs in the setter
because the kind can never be VR_NAN. This is a wart for
get_tree_range(), which builds a range out of a tree from the source,
to work correctly. It's ugly, an
NANs don't have bounds, so there's no need to stream them out.
gcc/ChangeLog:
* data-streamer-in.cc (streamer_read_value_range): Handle NANs.
* data-streamer-out.cc (streamer_write_vrange): Same.
* value-range.h (class vrange): Make streamer_write_vrange a friend.
---
gcc
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 +
>> Qing Zhao via Gcc-patches wrote:
>>
>>> GCC extension accepts the case when a struct wi
Hi Alexandre,
on 2023/5/24 13:51, Alexandre Oliva wrote:
>
> Codegen changes caused add instruction count mismatches on
> ppc-*-linux-gnu and other 32-bit ppc targets. At some point the
> expected counts were adjusted for lp64, but ilp32 differences
> remained, and published test results confirm
Committed, thanks Kito.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Thursday, May 25, 2023 12:02 PM
To: juzhe.zh...@rivai.ai
Cc: gcc-patches@gcc.gnu.org; pal...@rivosinc.com; rdapp@gmail.com;
jeffreya...@gmail.com
Subject: Re: [PATCH] RISC
On Wed, May 24, 2023 at 4:41 PM Eric Botcazou wrote:
>
> > But nobody is going to understand why the INTEGER_CST case goes the
> > other way.
>
> I can add a fat comment to that effect of course. :-)
>
> > As you say we don't have a good way to say we're doing
> > this to avoid undefined behavior,
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 options depending on optimizat
On Thu, 25 May 2023 at 01:28, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Wed, 24 May 2023 at 15:40, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > On Mon, 22 May 2023 at 14:18, Richard Sandiford
> >> > wrote:
> >> >>
> >> >> Prathamesh Kulkarni
From: Juzhe-Zhong
Currenty mode switching incorrect codegen for the following case:
void fn (void);
void f (void * in, void *out, int32_t x, int n, int m)
{
for (int i = 0; i < n; i++) {
vint32m1_t v = __riscv_vle32_v_i32m1 (in + i, 4);
vint32m1_t v2 = __riscv_vle32_v_i32m1_tu (v, in +
On Wed, May 24, 2023 at 8:36 PM Alexander Monakov wrote:
>
>
> On Wed, 24 May 2023, Richard Biener via Gcc-patches wrote:
>
> > I’d have to check the ISAs what they actually do here - it of course depends
> > on RTL semantics as well but as you say those are not strictly defined here
> > either.
>
From: Naveen H S
This patch adds support scalar_storage_order attribute to C++ front-end.
It treats the opposite order fields similar as the packed fields are
treated such that they will not bind to references.
For arrays, the attributes applies to the inner type rather than the array
type simila
101 - 172 of 172 matches
Mail list logo
