On Wed, Jun 18, 2025 at 2:39 PM H.J. Lu wrote:
>
> On Mon, Jun 16, 2025 at 4:14 PM Hongtao Liu wrote:
> >
> > >+enum redundant_load_kind
> > >+{
> > >+ LOAD_CONST0_VECTOR,
> > >+ LOAD_CONSTM1_VECTOR,
> > >+ LOAD_VECTOR
> > >+};
> > Perhaps rename to x86_cse_kind, X86_CSE_CONST0_VECTOR,
> > X86
On Mon, Jun 16, 2025 at 4:14 PM Hongtao Liu wrote:
>
> >+enum redundant_load_kind
> >+{
> >+ LOAD_CONST0_VECTOR,
> >+ LOAD_CONSTM1_VECTOR,
> >+ LOAD_VECTOR
> >+};
> Perhaps rename to x86_cse_kind, X86_CSE_CONST0_VECTOR,
> X86_CSE_CONSTM1_VECTOR, X86_CSE_VEC_DUP?
Fixed.
> LOAD sounds a bit amb
On Mon, May 26, 2025 at 2:30 PM H.J. Lu wrote:
>
> On Sun, May 25, 2025 at 7:02 PM H.J. Lu wrote:
> >
> > On Sun, May 25, 2025 at 8:12 AM H.J. Lu wrote:
> > >
> > > On Sun, May 25, 2025 at 7:47 AM H.J. Lu wrote:
> > > >
> > > > commit ef26c151c14a87177d46fd3d725e7f82e040e89f
> > > > Author: Rog
On 18/6/2025 09:07, Kito Cheng wrote:
Maybe it's a good time to create a -mtune=generic and copy-and-modify
from rocket?
Indeed, it appears to be the most suitable solution.
Thanks,
Yangyu Chen
On Wed, Jun 18, 2025 at 6:59 AM Jeff Law wrote:
On 6/17/25 10:51 AM, Yangyu Chen wrote:
Hi Honza,
Thanks for the fixes.
> On 18 Jun 2025, at 1:48 am, Jan Hubicka wrote:
>
> External email: Use caution opening links or attachments
>
>
> Hi,
> this patch makes afdo_adjust_guessed_profile more agressive on finding scales
> on the boundaries of connected components with no annotation
> Am 17.06.2025 um 23:04 schrieb Jakub Jelinek :
>
> Hi!
>
> The following testcase shows that while at runtime we handle conversions
> between _Decimal{64,128} and large _BitInt correctly, at compile time we
> mishandle them in both directions, in one direction we end up in ICE in
> decimal_
These failing cases all contain a situation where the cache is
attempting to update values involving a back edge. We propagate values
in the cache, and then recalculate range-on-entry values until the
values settle.
Unfortunately, we do not really have canonical representation for ranges
whi
Maybe it's a good time to create a -mtune=generic and copy-and-modify
from rocket?
On Wed, Jun 18, 2025 at 6:59 AM Jeff Law wrote:
>
>
>
> On 6/17/25 10:51 AM, Yangyu Chen wrote:
> >
> >
> > On 17/6/2025 20:42, Jeff Law wrote:
> >>
> >>
> >> On 6/16/25 10:08 PM, Dongyan Chen wrote:
> >>> Hi, I've
When I implemented the pc-relative support for power10 in GCC, I disabled using
pc-relative support for -mcmodel=large. At the time, I didn't want to dig into
the issues. It is now time to allow -mcmodel=large to generate pc-relative
code.
This patch allows -mcmodel=large to use prefixed addres
On 6/17/25 10:51 AM, Yangyu Chen wrote:
On 17/6/2025 20:42, Jeff Law wrote:
On 6/16/25 10:08 PM, Dongyan Chen wrote:
Hi, I've come across a question regarding the branch cost of gcc. In
the link
https://gcc.godbolt.org/z/hnddevd5h, gcc fails to recognize the
optimization
branch judgment
On 6/17/25 3:24 PM, Andrew Waterman wrote:
I designed Rocket, so I can confirm Yangyu's comment that the branch
misprediction penalty is usually 3 cycles. (It's actually 4 if the
address of the correct-path instruction is a 4-byte-long instruction
that isn't naturally aligned, but that shou
On Tue, Jun 17, 2025 at 5:43 AM Jeff Law wrote:
>
>
>
> On 6/16/25 10:08 PM, Dongyan Chen wrote:
> > Hi, I've come across a question regarding the branch cost of gcc. In the
> > link
> > https://gcc.godbolt.org/z/hnddevd5h, gcc fails to recognize the optimization
> > branch judgment, while llvm d
On 2025-05-07 12:59, Qing Zhao wrote:
Hi,
This is the 2nd version of the patch for:
Evaluate the object size by the size of the pointee type when the type
is a structure with flexible array member which is annotated with
counted_by.
Per the following discussion: (Questions on replacing a struc
>> }
>>+ finish_expr_stmt (body_use);
>Would it work to emit body_use where you build it, instead of separately for
>EH/non-EH?
Yes it works fine, as below, OK?
thanks
Iain
--- 8< ---
This implements the final piece of the revised CWG2563 wording;
"It exits the scope of promise only
Hi!
The following testcase shows that while at runtime we handle conversions
between _Decimal{64,128} and large _BitInt correctly, at compile time we
mishandle them in both directions, in one direction we end up in ICE in
decimal_from_integer callee because the char buffer is too short for the
nee
Am 17.06.25 um 19:44 schrieb Steve Kargl:
On Tue, Jun 17, 2025 at 12:05:34PM +0300, Janne Blomqvist wrote:
On Mon, Jun 16, 2025 at 9:41 PM Harald Anlauf wrote:
Am 16.06.25 um 02:18 schrieb Steve Kargl:
Harald,
I did a quick glance at the patch and did not see anything that
jumped out as nee
On Tue, Jun 17, 2025 at 12:05:34PM +0300, Janne Blomqvist wrote:
> On Mon, Jun 16, 2025 at 9:41 PM Harald Anlauf wrote:
> >
> > Am 16.06.25 um 02:18 schrieb Steve Kargl:
> > > Harald,
> > >
> > > I did a quick glance at the patch and did not see anything that
> > > jumped out as needing a change.
This is an assertion failure on code using a container aggregate in the
primitives referenced by the Aggregate aspect, which cannot work.
Tested on x86-64/Linux, applied on the mainline.
2025-06-17 Eric Botcazou
PR ada/120665
* sem_aggr.adb (Resolve_Container_Aggregate): Use
On 17/6/2025 20:42, Jeff Law wrote:
On 6/16/25 10:08 PM, Dongyan Chen wrote:
Hi, I've come across a question regarding the branch cost of gcc. In
the link
https://gcc.godbolt.org/z/hnddevd5h, gcc fails to recognize the
optimization
branch judgment, while llvm does. I eventually discovered
On 6/17/25 6:21 AM, Iain Sandoe wrote:
Hi Jason,
body use is still relevant. The solution to this is to increment
the use before calling promise.unhanded_exception().
I expected that the body cleanup would check iarc and not do the decrement if
iarc is true.
that also works, done as atta
On 17/06/25 18:35, Jan Hubicka wrote:
External email: Use caution opening links or attachments
From: Dhruv Chawla
This patch modifies afdo_set_bb_count to propagate profile information
to outline copies of functions if they are not inlined. This information
gets lost otherwise.
Signed-off-b
On 6/17/25 7:15 AM, Paul-Antoine Arras wrote:
This is part of my vector-scalar FMA series. See:
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679513.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685624.html
The attached patch handles vfmacc and vfmsac. However I ran into an
Hi,
this patch makes afdo_adjust_guessed_profile more agressive on finding scales
on the boundaries of connected components with no annotation. Originaly I
looked for edges into or out of the component with known AFDO counts and I also
haled edges from basic block with known AFDO count and known s
Hi,
while working on auto-FDO I noticed that we may run into ICE because we inline
function with count profile_count::zero to a call site with profile_count::zero.
What may go wrong is that the caller has local profile while callee may have
IPA profiles.
We used to turn all such counts to 0, but t
> On 17 Jun 2025, at 06:02, Jason Merrill wrote:
>
> On 6/16/25 4:00 PM, Iain Sandoe wrote:
>> Hi Jason
>>> On 11 Jun 2025, at 23:50, Jason Merrill wrote:
>>>
>>> On 6/9/25 4:12 PM, Iain Sandoe wrote:
There was some discussion of this in the PR116775 comments. In the
end I have mat
On Tue, Jun 17, 2025 at 4:03 PM Cui, Lili wrote:
>
> From: Lili Cui
>
> Hi Uros,
>
> This is patch v3, the main changes are as follows.
>
> 1. Added a pro_epilogue_adjust_stack_add_nocc in i386.md to add memory
> clobber for lea/mov.
> 2. Adjusted some formatting issues.
> 3. Added scan-rtl-dump
On 6/17/25 7:15 AM, Paul-Antoine Arras wrote:
This is part of my vector-scalar FMA series. See:
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679513.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685624.html
The attached patch handles vfmacc and vfmsac. However I ran into an
From: Lili Cui
Hi Uros,
This is patch v3, the main changes are as follows.
1. Added a pro_epilogue_adjust_stack_add_nocc in i386.md to add memory clobber
for lea/mov.
2. Adjusted some formatting issues.
3. Added scan-rtl-dumps for ia32 in shrink_wrap_separate.C.
Collected spec2017 performance
On 6/12/25 10:53 AM, Alfie Richards wrote:
The string_slice inherits from array_slice and is used to refer to a
substring of an array that is memory managed elsewhere without modifying
the underlying array.
For example, this is useful in cases such as when needing to refer to a
substring of a
On 6/17/25 1:58 AM, Umesh Kalappa wrote:
Testcase update with no regressed found for the following the changes.
gcc/ChangeLog:
* config/riscv/sync.md (lrsc_atomic_exchange):
Use the scratch reg for rd.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zalrsc.c: Ne
This is part of my vector-scalar FMA series. See:
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679513.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685624.html
The attached patch handles vfmacc and vfmsac. However I ran into an
issue while writing testcases. Since the add and
On 6/17/25 1:56 AM, Kito Cheng wrote:
Motivation of this patch is we want to use ld/sd if possible when zilsd
is enabled, however the subreg pass may split that into two lw/sw
instructions because the cost, and it only check cost for 64 bits reg move,
that's why we need adjust cost for 64 bit
> From: Dhruv Chawla
>
> This patch modifies afdo_set_bb_count to propagate profile information
> to outline copies of functions if they are not inlined. This information
> gets lost otherwise.
>
> Signed-off-by: Dhruv Chawla
>
> gcc/ChangeLog:
>
> * gcc/auto-profile.cc (count_info): Ad
On 6/16/25 12:53 PM, Iain Sandoe wrote:
When working on CWG2563 version 4, (using cleanups) I encountered an
issue where the possibility that initialisation of the saved self-handle
would interfere with the use of cleanups to handle exceptional cases.
The original reason for pre-computing the han
On 6/16/25 10:08 PM, Dongyan Chen wrote:
Hi, I've come across a question regarding the branch cost of gcc. In the link
https://gcc.godbolt.org/z/hnddevd5h, gcc fails to recognize the optimization
branch judgment, while llvm does. I eventually discovered that the value of the
branch
cost was t
> -Original Message-
> From: H.J. Lu
> Sent: Monday, June 16, 2025 10:08 PM
> To: Jan Hubicka
> Cc: Uros Bizjak ; Cui, Lili ; gcc-
> patc...@gcc.gnu.org; Liu, Hongtao ;
> mjgu...@gmail.com
> Subject: [PATCH v3] x86: Update memcpy/memset inline strategies for -
> mtune=generic
>
> On Mo
On 6/16/25 10:08 PM, Dongyan Chen wrote:
Hi, I've come across a question regarding the branch cost of gcc. In the link
https://gcc.godbolt.org/z/hnddevd5h, gcc fails to recognize the optimization
branch judgment, while llvm does. I eventually discovered that the value of the
branch
cost was t
On 6/16/25 11:55 PM, Jakub Jelinek wrote:
Hi!
The following testcase ICEs, because optimize_crc_loop inserts a call
statement before labels instead of after labels.
Fixed thusly (plus fixed other issues noticed around it),
bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/1
The old POSIX Fortran spec defined the PXFCONST subroutine and IPXFCONST
function to provide portable access to constants such as ERANGE. Perhaps
adding them to the gfortran library would be useful?
Walter
Sent from my iPhone
> On Jun 17, 2025, at 4:05 AM, Janne Blomqvist
> wrote:
>
> On
> Another problem here is that get_inline_stack returns an empty stack if
> no inlining occurred in the corresponding GIMPLE statement. So if an
> inline callsite does exist in the profile at the current GIMPLE
> statement but no inlining actually occurs during auto-profile, the
> information is ju
Hi!
Here is a new version of the library side of the C++26 P2786R13 paper.
For if constexpr the patch uses __builtin_constant_p trick to figure
out if __result is non-equality comparable with __first, it adds recursion
for the is_array_v cases, adds qualification on several calls and rewrites
the
> Am 17.06.2025 um 08:57 schrieb Jakub Jelinek :
>
> Hi!
>
> The following testcase ICEs, because optimize_crc_loop inserts a call
> statement before labels instead of after labels.
>
> Fixed thusly (plus fixed other issues noticed around it),
> bootstrapped/regtested on x86_64-linux and i68
On Mon, Jun 16, 2025 at 9:41 PM Harald Anlauf wrote:
>
> Am 16.06.25 um 02:18 schrieb Steve Kargl:
> > Harald,
> >
> > I did a quick glance at the patch and did not see anything that
> > jumped out as needing a change. OK to commit.
> >
> > Earlier today I came to the same conclusion that -1 on o
Agree @Jeff and updated the testcase .
Thank you
~Y
On Tue, Jun 17, 2025 at 8:46 AM Jeff Law wrote:
>
>
> On 6/11/25 2:47 AM, Umesh Kalappa wrote:
> > gcc/ChangeLog:
> >
> > * config/riscv/sync.md (lrsc_atomic_exchange):
> > Use the scratch reg for rd.
> >
> > gcc/testsuite/
Jeff and Segher, thanks for the clarifications and hints!
Bohan, I assume you will have a look at this (there is also PR119587
to keep track of it).
BR
Christoph
On Mon, Jun 9, 2025 at 6:28 PM Segher Boessenkool
wrote:
>
> On Mon, Jun 09, 2025 at 08:26:10AM -0600, Jeff Law wrote:
> > On 4/1/25
Hi Jason,
>>body use is still relevant. The solution to this is to increment
>>the use before calling promise.unhanded_exception().
> I expected that the body cleanup would check iarc and not do the decrement if
> iarc is true.
that also works, done as attached,
OK now?
thanks
Iain
--- 8< --
> On 16 Jun 2025, at 09:54, Richard Sandiford wrote:
>
> We generated inefficient code for bitfield references to Advanced
> SIMD structure modes. In RTL, these modes are just extra-long
> vectors, and so inserting and extracting an element is simply
> a vec_set or vec_extract operation.
>
>
> On 4 Apr 2025, at 20:28, ezra.sito...@arm.com wrote:
>
> From: Ezra Sitorus
>
> This patch updates `aarch64-sys-regs.def', bringing it into sync with
> the Binutils source after this change:
> https://sourceware.org/pipermail/binutils/2025-March/139894.html
Ok. I think these changes are co
Hi Jakub,
Jakub Jelinek wrote:
diff --git a/libgomp/testsuite/libgomp.c++/declare_target-2.C
b/libgomp/testsuite/libgomp.c++/declare_target-2.C
+// Actually not needed: -fipa-cp is default with -O2:
+// { dg-additional-options "-O2 -fipa-cp -foffload=amdgcn-amdhsa" }
But am not sure how this
On 28/05/2025 18:17, Karl Meakin wrote:
> The CB family of instructions does not support using the CS or CC
> condition codes; instead the synonyms HS and LO must be used. GCC has
> traditionally used the CS and CC names. To work around this while
> avoiding test churn, add new `j` and `J` format s
On Tue, Jun 17, 2025 at 10:07:04AM +0200, Tobias Burnus wrote:
> --- a/gcc/omp-offload.cc
> +++ b/gcc/omp-offload.cc
> @@ -261,7 +261,8 @@ omp_discover_declare_target_tgt_fn_r (tree *tp, int
> *walk_subtrees, void *data)
> DECL_ATTRIBUTES (decl)))
> return NULL_T
We often see timeouts when running these tests on simulator, and
Joern's patch apply cleanly (and fix the problem).
OK to backport to gcc-14?
Thanks,
Christophe
Joern Rennecke (2):
Reduce iteration counts for gcc.dg/vect/tsvc tests.
Fix PR testsuite/116271, gcc.dg/vect/tsvc/vect-tsvc-s176.c
From: Joern Rennecke
testsuite/
* gcc.dg/vect/tsvc/tsvc.h (iterations): Allow to override,
default to 10.
(get_expected_result): Add values for iterations counts
10, 256 and 3200.
(run): Add code to output values for new iterations counts.
* gcc.dg/
From: Joern Rennecke
gcc/testsuite:
PR testsuite/116271
* gcc.dg/vect/tsvc/vect-tsvc-s176.c [TRUNCATE_TEST]: Make sure
that m stays the same as the loop bound of the middle loop.
* gcc.dg/vect/tsvc/tsvc.h (get_expected_result) [TRUNCATE_TEST]:
Adjust expec
On 17/6/2025 12:08, Dongyan Chen wrote:
Hi, I've come across a question regarding the branch cost of gcc. In the link
https://gcc.godbolt.org/z/hnddevd5h, gcc fails to recognize the optimization
branch judgment, while llvm does. I eventually discovered that the value of the
branch
cost was to
This fixes an issue with implicit declare target.
'' has:
template … endl() { ... }
...
extern template ostream& endl(ostream&);
which leads to a decl that is 'extern' but still
has the full function body available.
Result: On the offload side, 'endl' is present
but the functions it calls
Testcase update with no regressed found for the following the changes.
gcc/ChangeLog:
* config/riscv/sync.md (lrsc_atomic_exchange):
Use the scratch reg for rd.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zalrsc.c: New test.
---
gcc/config/riscv/sync.md
Motivation of this patch is we want to use ld/sd if possible when zilsd
is enabled, however the subreg pass may split that into two lw/sw
instructions because the cost, and it only check cost for 64 bits reg move,
that's why we need adjust cost for 64 bit reg move as well.
However even we adjust t
Use riscv_v_ext_mode_p to check the mode size is 2x XLEN, instead of
using "(GET_MODE_UNIT_SIZE (mode) == (UNITS_PER_WORD * 2))".
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_legitimize_move): Use
riscv_2x_xlen_mode_p.
(riscv_binary_cost): Ditto.
(riscv_hard_regno
Thanks very much!
Dongyan Chen
在 2025/6/17 15:34, Yangyu Chen 写道:
On 17/6/2025 12:08, Dongyan Chen wrote:
Hi, I've come across a question regarding the branch cost of gcc. In
the link
https://gcc.godbolt.org/z/hnddevd5h, gcc fails to recognize the
optimization
branch judgment, while llvm d
60 matches
Mail list logo
