Hi Andrew,
> On 26 Jun 2024, at 23:02, Andrew Pinski wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Wed, Jun 26, 2024 at 12:40 AM Kyrylo Tkachov wrote:
>>
>> Hi all,
>>
>> This adds support for the NVIDIA Grace CPU to aarch64.
>> We reuse the tuning decisions f
On Thu, 27 Jun 2024, 05:05 Eric Gallager, wrote:
> On Wed, Jun 26, 2024 at 4:28 PM Jonathan Wakely
> wrote:
> >
> > Pushed to trunk. We have nearly a year to make improvements to it
> > before it's needed for the gcc-15 branch ... I just hope I remember it
> > exists when we branch ;-)
>
> Maybe
On Mon, Jun 24, 2024 at 3:55 PM wrote:
>
> From: Pan Li
>
> The zip benchmark of coremark-pro have one SAT_SUB like pattern but
> truncated as below:
>
> void test (uint16_t *x, unsigned b, unsigned n)
> {
> unsigned a = 0;
> register uint16_t *p = x;
>
> do {
> a = *--p;
> *p = (ui
Since middle-end patch is approved, LGTM this patch.
Thanks for improving RVV vectorization.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-06-25 20:40
To: gcc-patches
CC: juzhe.zhong; kito.cheng; richard.guenther; jeffreyalaw; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: Add testcases for vec
Hi Andre,
Thanks for resending the patches. I fear that daytime work and visitors
have taken my attention the last days - hence the delay in reviewing, for
which I apoloise,
The patches do what they are advertised to do, without regressions on my
side. I like gfc_class_set_vptr. Please remove the
I think we need to revert this.
I got this email from linaro/gcc-regressions:
[Linaro-TCWG-CI] gcc-15-1649-g19f630e6ae8d: FAIL: 2 regressions on aarch64
regressions.sum:
=== gcc tests ===
Running gcc:gcc.misc-tests/gcov.exp ...
FAIL: gcc.misc-tests/gcov-23.c (internal compiler
On Wed, Jun 26, 2024 at 11:10:38AM -0400, Paul Koning wrote:
>
>
> > On Jun 26, 2024, at 8:54 AM, Stefan Schulze Frielinghaus
> > wrote:
> >
> > On Tue, Jun 25, 2024 at 01:02:39PM -0400, Paul Koning wrote:
> >>
> >>
> >>> On Jun 25, 2024, at 12:04 PM, Stefan Schulze Frielinghaus
> >>> wrot
> OK.
Committed, thanks Richard.
Pan
-Original Message-
From: Richard Biener
Sent: Thursday, June 27, 2024 2:08 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com;
jeffreya...@gmail.com; rdapp@gmail.com
Subject: Re: [PATCH v2] Internal-fn: Sup
> OK
Committed, thanks Richard.
Pan
-Original Message-
From: Richard Biener
Sent: Thursday, June 27, 2024 2:04 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com;
jeffreya...@gmail.com; rdapp@gmail.com
Subject: Re: [PATCH v3] Vect: Support tru
On Thu, Jun 27, 2024 at 5:57 AM liuhongt wrote:
>
> > But rtx_cost invokes targetm.rtx_cost which allows to avoid that
> > recursive processing at any level. You're dealing with MEM [addr]
> > here, so why's rtx_cost (addr, Pmode, MEM, 0, speed) not always
> > the best way to deal with this? Sin
On Thu, Jun 13, 2024 at 3:32 PM Alexandre Oliva wrote:
>
>
> The first patch for PR113719 regressed gcc.dg/ipa/iinline-attr.c on
> toolchains configured to --enable-frame-pointer, because the
> optimization node created within handle_optimize_attribute had
> flag_omit_frame_pointer incorrectly set
On Thu, Jun 27, 2024 at 7:12 AM wrote:
>
> From: Pan Li
>
> This patch would like to add the middle-end presentation for the
> saturation truncation. Aka set the result of truncated value to
> the max value when overflow. It will take the pattern similar
> as below.
>
> Form 1:
> #define DEF_
On Thu, Jun 27, 2024 at 5:57 AM liuhongt wrote:
>
> > But rtx_cost invokes targetm.rtx_cost which allows to avoid that
> > recursive processing at any level. You're dealing with MEM [addr]
> > here, so why's rtx_cost (addr, Pmode, MEM, 0, speed) not always
> > the best way to deal with this? Sin
On Thu, Jun 27, 2024 at 3:31 AM wrote:
>
> From: Pan Li
OK
> The zip benchmark of coremark-pro have one SAT_SUB like pattern but
> truncated as below:
>
> void test (uint16_t *x, unsigned b, unsigned n)
> {
> unsigned a = 0;
> register uint16_t *p = x;
>
> do {
> a = *--p;
> *p =
From: Pan Li
This patch would like to add the middle-end presentation for the
saturation truncation. Aka set the result of truncated value to
the max value when overflow. It will take the pattern similar
as below.
Form 1:
#define DEF_SAT_U_TRUC_FMT_1(WT, NT) \
NT __attribute__((noinline))
On Wed, Jun 26, 2024 at 4:28 PM Jonathan Wakely wrote:
>
> Pushed to trunk. We have nearly a year to make improvements to it
> before it's needed for the gcc-15 branch ... I just hope I remember it
> exists when we branch ;-)
Maybe you could leave a note about it in the docs somewhere?
>
> On We
> But rtx_cost invokes targetm.rtx_cost which allows to avoid that
> recursive processing at any level. You're dealing with MEM [addr]
> here, so why's rtx_cost (addr, Pmode, MEM, 0, speed) not always
> the best way to deal with this? Since this is the MEM [addr] case
> we know it's not LEA, no?
LGTM!
Thanks very much!
在 2024/6/26 下午3:53, Xi Ruoyao 写道:
Ping.
On Sun, 2024-06-16 at 01:50 +0800, Xi Ruoyao wrote:
Consider
c &= 0xfff;
a &= ~0xfff;
b &= ~0xfff;
a |= c;
b |= c;
This can be done with 2 bstrins instructions. But we need to
recognize
it in loongarc
On 2024-06-27 08:52 wangfeng wrote:
I rebased the patch 3/3, there is a conflict. I will submit again after
internal code review.
Due to many changes, the patch was split, so a dependency relationship between
patch 2/3
and patch 3/3 was generated. Could you help pull both patches down when ru
On 6/26/24 7:27 PM, Oleg Endo wrote:
On Wed, 2024-06-26 at 18:30 -0600, Jeff Law wrote:
OK, then what's the default config of your test setup / triplet?
Can you please show the generated code that you get? Because - like I said
- I can't reproduce it.
test01:
sts.l pr,@-r15
Hi,
This patch implemented optab_isfinite for SFDF and IEEE128 by
test data class instructions.
Compared with previous version, the main change is to use the
constant mask for test data class insns.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652594.html
Bootstrapped and tested on po
Hi,
This patch implemented optab_isnormal for SFDF and IEEE128 by
test data class instructions.
Compared with previous version, the main change is to use the
constant mask for test data class insns.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652595.html
Bootstrapped and tested on po
Hi,
This patch implemented optab_isinf for SFDF and IEEE128 by test
data class instructions.
Compared with previous version, the main change is to define
and use the constant mask for test data class insns.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652593.html
Bootstrapped and test
From: Pan Li
The zip benchmark of coremark-pro have one SAT_SUB like pattern but
truncated as below:
void test (uint16_t *x, unsigned b, unsigned n)
{
unsigned a = 0;
register uint16_t *p = x;
do {
a = *--p;
*p = (uint16_t)(a >= b ? a - b : 0); // Truncate after .SAT_SUB
} while
On Wed, 2024-06-26 at 18:30 -0600, Jeff Law wrote:
> > >
> >
> > OK, then what's the default config of your test setup / triplet?
> > Can you please show the generated code that you get? Because - like I said
> > - I can't reproduce it.
> test01:
> sts.l pr,@-r15! 31[c=4 l
Hi, all
This patch aims to refactor vcvttps2qq/vcvtqq2ps patterns for remove redundant
round_*_modev8sf_condition.
Bootstrapped and regtested on x86-64-linux-gnu, OK for trunk?
BRs,
Lin
gcc/ChangeLog:
* config/i386/sse.md
(float2):
Refactor the pattern.
(unspe
On Thu, 27 Jun 2024, 01:53 Matthias Kretz, wrote:
> Ah, thank you. I didn't realize that there's a default for dg-do. I
> probably
> knew it back when I added check_vect_support_and_set_flags...
>
> OK for all branches from my side.
>
Yup, ok to push then, thanks.
> -Matthias
>
> On Wednesday
On 2024-06-22 00:16 Patrick O'Neill wrote:
>
>Hi Feng,
>
>Pre-commit has flagged a build-failure for patch 2/3:
>https://github.com/ewlu/gcc-precommit-ci/issues/1786#issuecomment-2181962244
>
>When applied to 9a76db24e04 i386: Allow all register_operand SUBREGs in
>x86_ternlog_idx.
>
>Re-confirme
Ah, thank you. I didn't realize that there's a default for dg-do. I probably
knew it back when I added check_vect_support_and_set_flags...
OK for all branches from my side.
-Matthias
On Wednesday, 26 June 2024 04:45:28 CDT Alexandre Oliva wrote:
> The newly-added testcase overrides the default
On 6/26/24 4:44 PM, Oleg Endo wrote:
On Wed, 2024-06-26 at 16:39 -0600, Jeff Law wrote:
On 6/26/24 4:12 PM, Oleg Endo wrote:
On Wed, 2024-06-26 at 07:22 -0600, Jeff Law wrote:
Surya's recent patch to IRA improves the code for sh/pr54602-1.c
slightly. Specifically it's able to eliminat
On Thu, 2023-11-23 at 17:17 -0500, Antoni Boucher wrote:
> Hi.
> I did split the patch and sent one for the bfloat16 support and
> another
> one for the vector support.
>
> Here's the updated patch for the machine-dependent builtins.
>
Thanks for the patch; sorry about the long delay in reviewin
On Wed, 2024-06-26 at 16:39 -0600, Jeff Law wrote:
>
> On 6/26/24 4:12 PM, Oleg Endo wrote:
> >
> >
> > On Wed, 2024-06-26 at 07:22 -0600, Jeff Law wrote:
> > > Surya's recent patch to IRA improves the code for sh/pr54602-1.c
> > > slightly. Specifically it's able to eliminate a save/restore
On 6/26/24 4:12 PM, Oleg Endo wrote:
On Wed, 2024-06-26 at 07:22 -0600, Jeff Law wrote:
Surya's recent patch to IRA improves the code for sh/pr54602-1.c
slightly. Specifically it's able to eliminate a save/restore in the
prologue/epilogue and a bit of register shuffling.
As a result there
On Wed, 2024-06-26 at 07:22 -0600, Jeff Law wrote:
> Surya's recent patch to IRA improves the code for sh/pr54602-1.c
> slightly. Specifically it's able to eliminate a save/restore in the
> prologue/epilogue and a bit of register shuffling.
>
> As a result there literally aren't any insns th
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This is a low-prio crash on invalid code where we ICE on a VAR_DECL
with erroneous type. I thought I'd try to avoid putting such decls
into ->names and ->names_in_scope but that sounds riskier than the
following cleanup.
On Wed, 2024-02-21 at 14:16 -0500, Antoni Boucher wrote:
> On Thu, 2023-12-07 at 19:57 -0500, David Malcolm wrote:
> > On Thu, 2023-12-07 at 17:26 -0500, Antoni Boucher wrote:
> > > Hi.
> > > This patch fixes getting the size of size_t (bug 112910).
> > >
> > > There's one issue with this patch: l
On Sun, 2024-03-10 at 12:05 +0100, Iain Buclaw wrote:
> Excerpts from David Malcolm's message of März 5, 2024 4:09 pm:
> > On Thu, 2023-11-09 at 19:33 -0500, Antoni Boucher wrote:
> > > Hi.
> > > See answers below.
> > >
> > > On Thu, 2023-11-09 at 18:04 -0500, David Malcolm wrote:
> > > > On Thu,
On Wed, 26 Jun 2024 at 21:39, François Dumont wrote:
>
> Hi
>
> Here is my proposal to add support for fancy allocator pointer.
>
> The only place where we still have C pointers is at the
> iterator::pointer level but it's consistent with std::list
> implementation and also logical considering tha
On Wed, Jun 26, 2024 at 08:01:57PM +0200, Martin Uecker wrote:
>
> Thanks Marek, here is the second version which should
> implement all your suggestions.
Thanks!
> (BTW: Without the newline of the end, the test case has
> undefined behavior..., not that we need to care.)
>
>
> Bootstrapped
On Wed, Jun 26, 2024 at 12:40 AM Kyrylo Tkachov wrote:
>
> Hi all,
>
> This adds support for the NVIDIA Grace CPU to aarch64.
> We reuse the tuning decisions for the Neoverse V2 core, but include a
> number of architecture features that are not enabled by default in
> -mcpu=neoverse-v2.
>
> This a
Hi
Here is my proposal to add support for fancy allocator pointer.
The only place where we still have C pointers is at the
iterator::pointer level but it's consistent with std::list
implementation and also logical considering that we do not get
value_type pointers from the allocator.
I also
Pushed to trunk. We have nearly a year to make improvements to it
before it's needed for the gcc-15 branch ... I just hope I remember it
exists when we branch ;-)
On Wed, 26 Jun 2024 at 00:13, Jonathan Wakely wrote:
>
> This script automates some updates that should be made when branching
> from
Tested x86_64-linux. Pushed to trunk.
-- >8 --
We currently have 808590.cc which only runs for C++98 mode, and
808590-cxx11.cc which only runs for C++11 and later, but have almost
identical content (except for a defaulted special member in the C++11
one, to suppress a -Wdeprecated-copy warning).
Pushed to trunk now.
On Thu, 20 Jun 2024 at 16:36, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> These tests compile very slowly in debug mode.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/90276
> *
> testsuite/25_algorithms/pstl/alg_modifying_operations/rotate
Pushed to trunk now.
On Thu, 20 Jun 2024 at 16:36, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> This addresses one known failure due to a bug in the upstream tests, and
> a number of timeouts due to the algorithms running much more slowly with
> debug mode checks enabled.
>
>
This is the final version, which is the same as v1 except for the typo
in a comment fixed, as noted in my May 2nd email.
Tested x86_64-linux, pushed to trunk.
-- >8 --
I found some issues in the std::chrono::tzdb parser by testing the
tzdata "vanguard" format, which uses new features that aren't
The case in the ticket is an ICE on invalid due to an assert in stabilize_expr,
but the underlying issue can actually trigger on this *valid* code:
=== cut here ===
struct TheClass {
TheClass() {}
TheClass(volatile TheClass& t) {}
TheClass operator=(volatile TheClass& t) volatile { return t;
Wednesday, June 26, 2024 5:56 PM
Andrew Pinski wrote:
>
> I think this caused profilebootstrap failure on x86_64-linux-gnu.
> I notice the definition of GOT_ALIAS_SET for all non mingw targets is
> now just -1. That seems very wrong to me.
> It was originally:
> ```
> alias_set_type
> x86_GOT_ali
Thanks Marek, here is the second version which should
implement all your suggestions.
(BTW: Without the newline of the end, the test case has
undefined behavior..., not that we need to care.)
Bootstrapped and regression tested on x86_64.
[PATCH] c: Error message for incorrect use of st
The previous fix breaks in the degenerate case when the discovered
last_stmt is equal to the first stmt in the block since then we
undo a required stmt advancement.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
PR tree-optimization/115652
* tree-vect-slp.cc (vect_sche
The following fixes the 2nd occurance of new_temp missed with the
previous fix.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
PR tree-optimization/115493
* tree-vect-loop.cc (vect_create_epilog_for_reduction): Use
first scalar result.
---
gcc/tree-vect-loop.c
And Sergei's movmem patch. Just trivial testsuite adjustment for an
option name change and a whitespace fix from me.
I've spun this in my tester for rv32 and rv64. I'll wait for pre-commit
CI before taking further action.
Just a reminder, this patch is designed to handle the case where we c
On Wed, Jun 26, 2024 at 02:15:18PM +0200, Stefan Schulze Frielinghaus wrote:
> An explicit check for address registers was not required so far since
> during register allocation the processing of address constraints was
> sufficient. However, address constraints themself do not check for
> REGNO_O
GCC maintainers:
The following patch updates the user documentation for the vec_ld, vec_lde,
vec_st and vec_ste built-ins to make it clearer that there are data alignment
requirements for these built-ins. If the data alignment requirements are not
followed, the data loaded or stored by these b
> I think your interpretation of "depends on" is reasonable, but it's not the
> way we've handled it for other extension dependencies. For the others we're
> treating "depends on" the way this code does, ie enabling the dependant
> extensions implicitly. IIRC that's how the RISC-V specs want it t
On Wed, Jun 26, 2024 at 4:58 PM Feng Xue OS wrote:
>
> Allow shift-by-induction for slp node, when it is single lane, which is
> aligned with the original loop-based handling.
OK.
Did you try whether we handle multiple lanes correctly? The simplest
case would be a loop
body with say
a[2*i] =
On Wed, 26 Jun 2024 08:50:57 PDT (-0700), Andrea Parri wrote:
Tested using amo.exp with rv64gc_zalrsc, rv64id_zaamo, rv64id_zalrsc,
rv64id_zabha (using tip-of-tree qemu w/ zabha patches [2] applied for
execution tests).
My interpretation of the Zabha specification, in particular of "The Zabha
e
On 6/25/24 14:34, Jeff Law wrote:
On 6/25/24 3:14 PM, Patrick O'Neill wrote:
This is another round of AMO testcase cleanup. Consolidates a lot of
testcases
and unifies the testcase names.
Patrick O'Neill (3):
RISC-V: Rename amo testcases
RISC-V: Consolidate amo testcase variants
R
> > My interpretation of the Zabha specification, in particular of "The Zabha
> > extension depends upon the Zaamo standard extension", is that rv64id_zabha
> > should result in a dependency violation (some compiler warning).
> >
> > The changes at stake seem instead to make the Zabha extension "s
On 6/26/24 08:50, Andrea Parri wrote:
Tested using amo.exp with rv64gc_zalrsc, rv64id_zaamo, rv64id_zalrsc,
rv64id_zabha (using tip-of-tree qemu w/ zabha patches [2] applied for
execution tests).
My interpretation of the Zabha specification, in particular of "The Zabha
extension depends upon th
On Thu, 20 Jun 2024, YunQiang Su wrote:
> MIPSr6 removes condition trap instructions with imm, so the instruction
> like `teq $2,imm` will be converted to
> li $at, imm
> teq $2, $at
>
> The current version of Gas cannot detect if imm is zero, and output
> teq $2, $0
> Let's do it in GCC.
On Fri, Jun 7, 2024 at 2:45 AM Evgeny Karpov
wrote:
>
> Hello,
>
> Thank you for reviewing v1!
> v2 addresses all comments on v1.
>
> Changes in v2:
> - Move winnt.h and winnt-dll.h to config.gcc.
> - Resolve the issue with GCC GC in winnt-dll.cc.
> - Add definitions for GOT_ALIAS_SET,
> PE_COFF_
> Tested using amo.exp with rv64gc_zalrsc, rv64id_zaamo, rv64id_zalrsc,
> rv64id_zabha (using tip-of-tree qemu w/ zabha patches [2] applied for
> execution tests).
My interpretation of the Zabha specification, in particular of "The Zabha
extension depends upon the Zaamo standard extension", is tha
On Wed, 2024-02-21 at 10:56 -0500, Antoni Boucher wrote:
> Thanks for the review.
> Here's the updated patch.
Thanks for the update patch; sorry for the delay in reviewing.
The updated patch looks good for trunk.
Dave
>
> On Fri, 2023-12-01 at 12:45 -0500, David Malcolm wrote:
> > On Thu, 2023
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This works:
template
int Func(T);
typedef int (*funcptrtype)(int);
funcptrtype fp0 = &Func;
but this doesn't:
funcptrtype fp2 = (0, &Func);
because we only call resolve_nondeduced_context on the LHS (via
convert_to
On Thu, 2024-01-25 at 07:52 -0500, Antoni Boucher wrote:
> Thanks.
> Can we please agree on some wording to use so I know when the patch
> can
> be pushed. Especially since we're now in stage 4, it would help me if
> you say something like "you can push to master".
Sorry about the ambiguity.
Yes,
On Fri, 2024-02-23 at 09:55 -0500, Antoni Boucher wrote:
> I had forgotten to add the doc since there is now a new API.
> Here it is.
Sorry for the delay; the updated patch looks good to me (but may need
usual ABI tag changes when pushing).
Thanks
Dave
>
> On Wed, 2024-02-21 at 19:45 -0500, An
On Thu, 2024-04-04 at 18:59 -0400, Antoni Boucher wrote:
> Hi.
> This patch adds a new API to produce an rvalue representing the
> alignment of a type.
> Thanks for the review.
Patch looks good to me (but may need the usual ABI version updates when
merging).
Thanks; sorry for the delay in review
On Mon, 2024-04-22 at 19:56 +0200, Guillaume Gomez wrote:
> `param` is also inheriting from `lvalue`. I don't think adding this
> check is a good idea
> because it will not evolve nicely if more changes are done in
> libgccjit.
Sorry for not responding earlier.
I think I agree with Guillaume here
> On Jun 26, 2024, at 8:54 AM, Stefan Schulze Frielinghaus
> wrote:
>
> On Tue, Jun 25, 2024 at 01:02:39PM -0400, Paul Koning wrote:
>>
>>
>>> On Jun 25, 2024, at 12:04 PM, Stefan Schulze Frielinghaus
>>> wrote:
>>>
>>> On Tue, Jun 25, 2024 at 10:03:34AM -0400, Paul Koning wrote:
>
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we ICE in c_expr_sizeof_expr on an erroneous expr.value. The
code checks for expr.value == error_mark_node but here the e_m_n is
wrapped in a C_MAYBE_CONST_EXPR. I don't think we should have created
such a tree, so let's
Allow shift-by-induction for slp node, when it is single lane, which is
aligned with the original loop-based handling.
Thanks,
Feng
---
gcc/tree-vect-stmts.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index ca6052662a3..8
Allow shift-by-induction for slp node, when it is single lane, which is
aligned with the original loop-based handling.
Thanks,
Feng
---
gcc/tree-vect-stmts.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index ca6052662a3..8
This patch is also adjusted with changes to two its dependent patches.
When transforming multiple lane-reducing operations in a loop reduction chain,
originally, corresponding vectorized statements are generated into def-use
cycles starting from 0. The def-use cycle with smaller index, would conta
Updated the patch.
For lane-reducing operation(dot-prod/widen-sum/sad) in loop reduction, current
vectorizer could only handle the pattern if the reduction chain does not
contain other operation, no matter the other is normal or lane-reducing.
Actually, to allow multiple arbitrary lane-reducing o
Updated the patches based on comments.
The input vectype of reduction PHI statement must be determined before
vect cost computation for the reduction. Since lance-reducing operation has
different input vectype from normal one, so we need to traverse all reduction
statements to find out the input v
> I suppose the other patterns can see similar enhacements for the case
> their forms
> show up truncated or extended?
Yes, just want to highlight that this form comes from the zip benchmark.
Of course, the rest forms are planed in underlying Patch(es).
> Please use NOP_EXPR here.
Sure, and will
Thanks Richard, will address the comments in v2.
Pan
-Original Message-
From: Richard Biener
Sent: Wednesday, June 26, 2024 9:52 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com;
jeffreya...@gmail.com; rdapp@gmail.com
Subject: Re: [PATCH v1]
The mail I pointed to (
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647966.html ) is an answer
to the topic started by Dimitrije Milošević. I replied to the topic in the same
way as you answered here:
https://sourceware.org/pipermail/gcc-patches/2022-October/604298.html .
The meaning o
On Wed, 26 Jun 2024, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Wednesday, June 26, 2024 2:23 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> > Subject: Re: [PATCH]middle-end: Implement conditonal store vector
On Linux/x86_64,
3b9b8d6cfdf59337f4b7ce10ce92a98044b2657b is the first bad commit
commit 3b9b8d6cfdf59337f4b7ce10ce92a98044b2657b
Author: Surya Kumari Jangala
Date: Tue Jun 25 08:37:49 2024 -0500
ira: Scale save/restore costs of callee save registers with block frequency
caused
FAIL: gcc
On Mon, Jun 24, 2024 at 3:55 PM wrote:
>
> From: Pan Li
>
> The zip benchmark of coremark-pro have one SAT_SUB like pattern but
> truncated as below:
>
> void test (uint16_t *x, unsigned b, unsigned n)
> {
> unsigned a = 0;
> register uint16_t *p = x;
>
> do {
> a = *--p;
> *p = (ui
On Wed, Jun 26, 2024 at 3:46 AM wrote:
>
> From: Pan Li
>
> This patch would like to add the middle-end presentation for the
> saturation truncation. Aka set the result of truncated value to
> the max value when overflow. It will take the pattern similar
> as below.
>
> Form 1:
> #define DEF_
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, June 26, 2024 2:23 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: Re: [PATCH]middle-end: Implement conditonal store vectorizer pattern
> [PR115531]
>
> On Tue, 25 Jun 2024, Tamar
On Tue, 25 Jun 2024, Tamar Christina wrote:
> Hi All,
>
> This adds a conditional store optimization for the vectorizer as a pattern.
> The vectorizer already supports modifying memory accesses because of the
> pattern
> based gather/scatter recognition.
>
> Doing it in the vectorizer allows us
Surya's recent patch to IRA improves the code for sh/pr54602-1.c
slightly. Specifically it's able to eliminate a save/restore in the
prologue/epilogue and a bit of register shuffling.
As a result there literally aren't any insns that can be used to fill
the delay slot of the return, so a nop
Surya's recent patch to IRA improves the code for sh/pr54602-1.c
slightly. Specifically it's able to eliminate a save/restore in the
prologue/epilogue and a bit of register shuffling.
As a result there literally aren't any insns that can be used to fill
the delay slot of the return, so a nop
Stefan Schulze Frielinghaus writes:
> An explicit check for address registers was not required so far since
> during register allocation the processing of address constraints was
> sufficient. However, address constraints themself do not check for
> REGNO_OK_FOR_{BASE,INDEX}_P. Thus, with the ne
Surya's patch to IRA has improved the code we generate for one of the
thead store pair tests for both rv32 and rv64. This patch adjusts the
expectations of that test.
I've verified that the test now passes on rv32 and rv64 in my tester.
Pushing to the trunk.
Jeffcommit 03a3dffa43145f80548d3
On Tue, Jun 25, 2024 at 01:02:39PM -0400, Paul Koning wrote:
>
>
> > On Jun 25, 2024, at 12:04 PM, Stefan Schulze Frielinghaus
> > wrote:
> >
> > On Tue, Jun 25, 2024 at 10:03:34AM -0400, Paul Koning wrote:
> >>
> > ...
> > could be rewritten into
> >
> > int test (int x, int
On Wed, Jun 26, 2024 at 2:28 PM Aleksandar Rakic
wrote:
>
> Hi!
>
> I'd like to ping the following patch:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647966.html
> a patch for the computation of the complexity for the unsupported
> addressing modes in ivopts
The thread starting at
On Wed, Jun 5, 2024 at 11:07 AM Richard Biener wrote:
>
> On Tue, 4 Jun 2024, Manolis Tsamis wrote:
>
> > This change adds a function that checks for SLP nodes with multiple
> > occurrences
> > of the same statement (e.g. {A, B, A, B, ...}) and tries to rearrange the
> > node
> > so that there a
The following fixes wrong-code when using outer loop vectorization
and an inner loop SLP access with permutation. A wrong adjustment
to the IV increment is then applied on GCN.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
PR tree-optimization/115640
* tree-vect-stmt
This is a reworked implementation that only deduplicates two_operators
nodes and supports arbitrary orderings.
Based on the discussion on the original submission, I have made some
SPEC runs to see if this transformation applies to any other
benchmarks.
Aside from x264 this now triggers on SPEC2017
Hi!
I'd like to ping the following patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647966.html
a patch for the computation of the complexity for the unsupported addressing
modes in ivopts
This patch should be a fix for the bug which is described on the following
link:
https:/
This patch fixes the backend pattern that was printing the wrong input
scalar register pair when inserting into lane 1.
Added a new test to force float-abi=hard so we can use scan-assembler to
check
correct codegen.
Regression tested arm-none-eabi with
-march=armv8.1-m.main+mve/-mfloat-abi=ha
An explicit check for address registers was not required so far since
during register allocation the processing of address constraints was
sufficient. However, address constraints themself do not check for
REGNO_OK_FOR_{BASE,INDEX}_P. Thus, with the newly introduced
late-combine pass in r15-1579-
This change checks when a two_operators SLP node has multiple occurrences of
the same statement (e.g. {A, B, A, B, ...}) and tries to rearrange the operands
so that there are no duplicates. Two vec_perm expressions are then introduced
to recreate the original ordering. These duplicates can appear d
The following adjusts how SLP computes the insertion location. In
particular it advanced the insert iterator of the found last_stmt.
The vectorizer will later insert stmts _before_ it. But we also
have the constraint that possibly masked ops may not be scheduled
outside of the loop and as we do n
Hi,
This is the lasted version, I modified some comments and retest the patch on
x86-64-linux-gnu. I'll wait another day to see what else Tamar has to say
about the API, if not I will upstream this patch tomorrow.
BRs,
Lin
gcc/ChangeLog:
PR target/107432
* tree-vect-generic.cc
1 - 100 of 116 matches
Mail list logo
