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
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, 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 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, 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
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-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
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 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 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 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
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 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
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
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 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
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
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
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_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
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
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
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
> 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?
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
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 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 =
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 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 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 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
> 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
> 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
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
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
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
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
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 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
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 Wed, Jun 26, 2024 at 2:52 PM Richard Biener
wrote:
>
> On Wed, Jun 26, 2024 at 8:09 AM liuhongt wrote:
> >
> > 416.gamess regressed 4-6% on x86_64 since my r15-882-g1d6199e5f8c1c0.
> > The commit adjust rtx_cost of mem to reduce cost of (add op0 disp).
> > But Cost of ADDR could be cheaper tha
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 allows Grace users to more simply target the CPU with -mcpu=grace
rather
On Wed, 26 Jun 2024 at 01:27, Iain Sandoe wrote:
>
>
>
> > On 25 Jun 2024, at 22:59, Evgeny Karpov wrote:
> >
> > The patch fixes the issue introduced in
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=63512c72df09b43d56ac7680cdfd57a66d40c636
> > and reported at
> > https://gcc.gnu.org/pipermai
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 loongarch_rtx_costs or the compiler will not propagate
Ping.
On Sat, 2024-06-15 at 21:47 +0800, Xi Ruoyao wrote:
> The first form has a lower latency (due to the special handling of
> "move" in LA464 and LA664) despite it's longer.
>
> gcc/ChangeLog:
>
> * config/loongarch/loongarch.md (define_peephole2): Require
> optimize_insn_for_size
On Wed, Jun 26, 2024 at 9:14 AM Hongtao Liu wrote:
>
> On Wed, Jun 26, 2024 at 2:52 PM Richard Biener
> wrote:
> >
> > On Wed, Jun 26, 2024 at 8:09 AM liuhongt wrote:
> > >
> > > 416.gamess regressed 4-6% on x86_64 since my r15-882-g1d6199e5f8c1c0.
> > > The commit adjust rtx_cost of mem to redu
On Wed, Jun 26, 2024 at 4:02 PM Richard Biener
wrote:
>
> On Wed, Jun 26, 2024 at 9:14 AM Hongtao Liu wrote:
> >
> > On Wed, Jun 26, 2024 at 2:52 PM Richard Biener
> > wrote:
> > >
> > > On Wed, Jun 26, 2024 at 8:09 AM liuhongt wrote:
> > > >
> > > > 416.gamess regressed 4-6% on x86_64 since my
On 6/20/24 4:36 PM, Richard Biener wrote:
Am 20.06.2024 um 16:05 schrieb Andrew MacLeod :
On 6/20/24 05:31, Richard Biener wrote:
On Thu, 20 Jun 2024, Aldy Hernandez wrote:
Hi.
I came around to this, and whipped up the proposed patch. However, it
does seem a bit verbose, and I'm wond
Hi Andrew,
I’ve tested the fix for PR 115618 from your commit r14-6612-g8d30107455f230 on
the GCC 13 branch.
I’d like to back port it to that branch.
Is there any problem with that I should be aware of?
It applies cleanly and tests fine.
Thanks,
Kyrill
;; We always avoid the shift operation in bstrins__for_ior_mask
-;; if possible, but the result may be sub-optimal when one of the
masks
+;; if possible, but the result may be larger when one of the masks
;; is (1 << N) - 1 and one of the src register is the dest register.
;; For example
On Wed, May 29, 2024 at 5:06 PM David Malcolm wrote:
>
> On Wed, 2024-05-29 at 16:35 -0400, Eric Gallager wrote:
> > On Tue, May 28, 2024 at 1:21 PM David Malcolm
> > wrote:
> > >
> > > Ping.
> > >
> > > This patch has actually been *very* helpful to me when debugging
> > > selftest failures invo
The newly-added testcase overrides the default dg-do action set by
check_vect_support_and_set_flags (in libstdc++-dg/conformance.exp), so
it attempts to run the test even if runtime vector support is not
available.
Remove the explicit dg-do directive, so that the default is honored,
and the test
On 6/25/24 23:37, Jeff Law wrote:
On 6/25/24 2:04 AM, Jørgen Kvalsvik wrote:
Make gcov aware which edges are the true/false to more accurately
reconstruct the CFG. There are plenty of bits left in arc_info and it
opens up for richer reporting.
gcc/ChangeLog:
* gcov-io.h (GCOV_ARC_TRUE):
On 6/25/24 12:23, Jan Hubicka wrote:
The value vec objects are destroyed on exit, but release still needs to
be called explicitly.
gcc/ChangeLog:
* tree-profile.cc (find_conditions): Release vectors before
return.
I wonder if you turn
hash_map, vec> exprs;
to
hash_m
On 6/25/24 12:23, Jan Hubicka wrote:
gcc/ChangeLog:
* doc/gcov.texi: Add MC/DC section.
OK,
thanks!
Pushed.
Thanks,
Jørgen
Honza
---
gcc/doc/gcov.texi | 72 +++
1 file changed, 72 insertions(+)
diff --git a/gcc/doc/gcov.texi b/gcc/do
On 6/25/24 12:25, Jan Hubicka wrote:
Without key terms like "masking" and "MC/DC" it is not at all obvious
what --conditions actually reports on, and there is no easy path for the
user to figure out. By at least including the two key terms MC/DC and
masking users have something to search for.
gc
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
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
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
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 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
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 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
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
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
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 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
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
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 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
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
> -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 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_
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 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 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
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
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]
> 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
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
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
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
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
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
> 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:
>
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 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 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-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,
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 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
> 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 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_
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 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
> > 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/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
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
1 - 100 of 116 matches
Mail list logo
