On Tue, 16 Jan 2024, juzhe.zh...@rivai.ai wrote:
> >> That's probably because we have vect_variable_length && vect128 instead?
> Yes. Both RVV and SVE uses 128bit vector SLP.
>
> The optimized IR (both ARM SVE and RVV are similiar):
> vect__1.5_189 = MEM [(int *)x_50(D)];
> vect__1.6_191 =
On Tue, 16 Jan 2024, Juzhe-Zhong wrote:
> Notice there is a regression recently:
> XPASS: gcc.dg/vect/bb-slp-subgroups-3.c -flto -ffat-lto-objects
> scan-tree-dump-times slp2 "optimized: basic block" 2
> XPASS: gcc.dg/vect/bb-slp-subgroups-3.c scan-tree-dump-times slp2 "optimized:
> basic
>> That's probably because we have vect_variable_length && vect128 instead?
Yes. Both RVV and SVE uses 128bit vector SLP.
The optimized IR (both ARM SVE and RVV are similiar):
vect__1.5_189 = MEM [(int *)x_50(D)];
vect__1.6_191 = MEM [(int *)x_50(D) + 16B];
mask__2.7_192 = vect__1.5_189
On Tue, 16 Jan 2024, Juzhe-Zhong wrote:
> Recently notice there is a XPASS in RISC-V:
> XPASS: gcc.dg/vect/bb-slp-43.c -flto -ffat-lto-objects scan-tree-dump-not
> slp2 "vector operands from scalars"
> XPASS: gcc.dg/vect/bb-slp-43.c scan-tree-dump-not slp2 "vector operands from
> scalars"
>
>
On Mon, 15 Jan 2024, Robin Dapp wrote:
> I gave it another shot now by introducing a separate function as
> Richard suggested. It's probably not at the location he intended.
>
> The way I read the discussion there hasn't been any consensus
> on how (or rather where) to properly tackle the
Notice there is a regression recently:
XPASS: gcc.dg/vect/bb-slp-subgroups-3.c -flto -ffat-lto-objects
scan-tree-dump-times slp2 "optimized: basic block" 2
XPASS: gcc.dg/vect/bb-slp-subgroups-3.c scan-tree-dump-times slp2 "optimized:
basic block" 2
Checked on both ARM SVE an RVV:
Recently notice there is a XPASS in RISC-V:
XPASS: gcc.dg/vect/bb-slp-43.c -flto -ffat-lto-objects scan-tree-dump-not slp2
"vector operands from scalars"
XPASS: gcc.dg/vect/bb-slp-43.c scan-tree-dump-not slp2 "vector operands from
scalars"
And checked both ARM SVE and RVV:
在 2024/1/16 下午2:20, Xi Ruoyao 写道:
On Tue, 2024-01-16 at 14:16 +0800, chenglulu wrote:
在 2024/1/16 下午1:34, Xi Ruoyao 写道:
Ping.
On Fri, 2023-12-15 at 20:56 +0800, Xi Ruoyao wrote:
We don't allow SImode in FCC, so constraint z is never really used
here.
gcc/ChangeLog:
*
On Tue, 2024-01-16 at 14:16 +0800, chenglulu wrote:
>
>
> 在 2024/1/16 下午1:34, Xi Ruoyao 写道:
> > Ping.
> >
> > On Fri, 2023-12-15 at 20:56 +0800, Xi Ruoyao wrote:
> > > We don't allow SImode in FCC, so constraint z is never really used
> > > here.
> > >
> > > gcc/ChangeLog:
> > >
> > > *
在 2024/1/16 下午1:34, Xi Ruoyao 写道:
Ping.
On Fri, 2023-12-15 at 20:56 +0800, Xi Ruoyao wrote:
We don't allow SImode in FCC, so constraint z is never really used
here.
gcc/ChangeLog:
* config/loongarch/loongarch.md (movsi_internal): Remove
constraint z.
---
Bootstrapped and
I'm going to check-in this if no objection
Hongyu Wang 于2024年1月9日周二 15:14写道：
>
> Hi,
>
> This patch adds missing description for inline asm behavior and related
> compiler switch for APX.
>
> Ok for gcc-wwwdocs?
>
> ---
> htdocs/gcc-14/changes.html | 6 ++
> 1 file changed, 6 insertions(+)
Ping.
On Fri, 2023-12-15 at 20:56 +0800, Xi Ruoyao wrote:
> We don't allow SImode in FCC, so constraint z is never really used
> here.
>
> gcc/ChangeLog:
>
> * config/loongarch/loongarch.md (movsi_internal): Remove
> constraint z.
> ---
>
> Bootstrapped and regtested on
On Tue, 2024-01-16 at 10:57 +0800, chenxiaolong wrote:
> 在 2024-01-15一的 15:50 +0800，Xi Ruoyao写道：
> > On Mon, 2024-01-15 at 15:10 +0800, chenxiaolong wrote:
> > > At 14:42 +0800 on the first day of 2024-01-15, Xi Ruoyao wrote：
> > > > On Mon, 2024-01-15 at 14:32 +0800, YunQiang Su wrote:
> > > > >
LGTM, the big endian for RISC-V has been there for a while, but we
don't pay enough attention to that, so I think reporting sorry for now
is a very reasonable way :)
On Tue, Jan 16, 2024 at 11:05 AM Juzhe-Zhong wrote:
>
> As PR113404 mentioned: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113404
As PR113404 mentioned: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113404
We have ICE when we enable RVV in big-endian mode:
during RTL pass: expand
a-float-point-dynamic-frm-66.i:2:14: internal compiler error: in to_constant,
at poly-int.h:588
0xab4c2c poly_int<2u, unsigned
在 2024-01-15一的 15:50 +0800，Xi Ruoyao写道：
> On Mon, 2024-01-15 at 15:10 +0800, chenxiaolong wrote:
> > At 14:42 +0800 on the first day of 2024-01-15, Xi Ruoyao wrote：
> > > On Mon, 2024-01-15 at 14:32 +0800, YunQiang Su wrote:
> > > > Xi Ruoyao wrote at 12:11pm on Monday,
> > > > January
> > > >
Hi,
As pointed out by the discussion in PR109705, the current
vect_long_mult effective target check on Power is broken.
This patch is to fix it accordingly.
With additional change by adding a guard vect_long_mult
in gcc.dg/vect/pr25413a.c , it's tested well on Power{8,9}
LE & BE (also on Power10
Define LOGICAL_OP_NON_SHORT_CIRCUIT as 0, for a short-circuit branch, use the
short-circuit operation instead of the non-short-circuit operation.
SPEC2017 performance evaluation shows 1% performance improvement for fprate
GEOMEAN and no obvious regression for others. Especially, 526.blender_r
In r14-7022-34d339bbd0c1f5b4ad9587e7ae8387c912cb028b I implement pattern
vec_concatz, the reg+reg addressing mode is not supported in
vec_concatz. This patch fixes that.
gcc/ChangeLog:
* config/loongarch/lasx.md (vec_concatz): Fix pattern to
support reg+reg addressing mode.
For below pattern, can be treated as a simple move because floating point
and vector share a common register on loongarch64.
(set (reg/v:SF 32 $f0 [orig:93 res ] [93])
(vec_select:SF (reg:V8SF 32 $f0 [115])
(parallel [
(const_int 0 [0])
])))
Hi,
This patch adds const0 move checking for CLEAR_BY_PIECES. The original
vec_duplicate handles duplicates of non-constant inputs. But 0 is a
constant. So even a platform doesn't support vec_duplicate, it could
still do clear by pieces if it supports const0 move by that mode.
The test cases
This patch resolves PR rtl-optimization/111267 by improving RTL-level
forward propagation. This x86_64 code quality regression was caused
(exposed) by my changes to improve how x86's (TImode) argument passing
is represented at the RTL-level (reducing the use of SUBREGs to catch
more optimization
On Mon, 15 Jan 2024, Jonathan Wakely wrote:
> I think I'm happy with this now. It has tests for all the new functions,
> and the performance of the charset alias match algorithm is improved by
> reusing part of .
>
> Tested x86_64-linux.
>
> -- >8 --
>
> This is another C++26 change, approved
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r14-7266-gce27b66d952127.
gcc/analyzer/ChangeLog:
PR analyzer/106229
* analyzer.h (compare_constants): New decl.
*
In particular, accessing the result of *calloc (1, SZ) (if non-NULL)
should be known to be all zeroes.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r14-7265-gd235bf2e807c5f.
On 1/8/24 10:27, Patrick Palka wrote:
On Mon, 8 Jan 2024, Nathaniel Shead wrote:
On Thu, Jan 04, 2024 at 03:39:15PM -0500, Patrick Palka wrote:
On Sun, 3 Dec 2023, Nathaniel Shead wrote:
The TYPE_DECL_SUPPRESS_DEBUG and DECL_EXTERNAL flags use the same
underlying bit. This is causing
On 1/9/24 03:52, Jakub Jelinek wrote:
Hi!
The copy attributes is allowed on decls as well as types and even has
checks whether decl (set to *node) is DECL_P or TYPE_P, but for diagnostics
unconditionally uses DECL_SOURCE_LOCATION (decl), which obviously only works
if it applies to a decl.
In
On 1/11/24 01:12, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu. OK for trunk?
-- >8 --
Currently, thread_locals in header modules cause ICEs. This patch makes
the required changes for them to work successfully.
Functions exported by a module need DECL_CONTEXT to be
On Mon, Jan 15, 2024 at 9:45 PM Jonathan Wakely wrote:
> I think I'm happy with this now. It has tests for all the new functions,
> and the performance of the charset alias match algorithm is improved by
> reusing part of .
>
> Tested x86_64-linux.
Looks good to me. Good work, Jon.
Hello Richard:
On 15/01/24 6:25 pm, Ajit Agarwal wrote:
>
>
> On 15/01/24 6:14 pm, Ajit Agarwal wrote:
>> Hello Richard:
>>
>> On 15/01/24 3:03 pm, Richard Biener wrote:
>>> On Sun, Jan 14, 2024 at 4:29 PM Ajit Agarwal wrote:
Hello All:
This patch add the vecload pass to
It is time to add myself to DCO section for my quicinc email account.
ChangeLog:
* MAINTAINERS (DCO): Add myself.
Signed-off-by: Andrew Pinski
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 882694cc47d..cb5a42501dd 100644
---
On 1/15/24 17:14, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK, thanks.
-- >8 --
Here we started crashing with r14-1659 because that removed the
auto checking in cp_parser_template_type_arg which seemed like
dead code. But the attached test shows
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we started crashing with r14-1659 because that removed the
auto checking in cp_parser_template_type_arg which seemed like
dead code. But the attached test shows that the code can still
be reached because
Evening folks,
Hope you had wonderful holidays.
Gentle ping on this patch.
Have a lovely night!
--
Arsen Arsenović
signature.asc
Description: PGP signature
On 11 January 2024 10:59:21 CET, YunQiang Su wrote:
>Fix build warning:
> mips.cc: warning: unused parameter 'decl'.
>
>gcc
> * config/mips/mips.cc (mips_start_function_definition):
> Add ATTRIBUTE_UNUSED.
>---
> gcc/config/mips/mips.cc | 3 ++-
> 1 file changed, 2 insertions(+), 1
On 1/15/24 04:41, Nathaniel Shead wrote:
While working on another bug, I noticed the ENABLE_SCOPE_CHECKING macro
and thought to try it out. It caused selftest to ICE. This patch is a
minimal fix to get it working again.
Probably this should use a test to stop this regressing again in the
future
On 1/8/24 13:40, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/13/12?
OK.
-- >8 --
The get_target_expr call added in r12-7069-g119cea98f66476 causes us
for the below testcase to call build_vec_delete in a template context,
which builds a
On 1/5/24 11:50, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk and perhaps 13?
-- >8 --
invalid_tparm_referent_p was rejecting using the address of a class NTTP
object as a template argument, but this should be fine.
Hmm, I suppose so;
I think I'm happy with this now. It has tests for all the new functions,
and the performance of the charset alias match algorithm is improved by
reusing part of .
Tested x86_64-linux.
-- >8 --
This is another C++26 change, approved in Varna 2022. We require a new
static array of data that is
On Mon, 15 Jan 2024 at 19:32, Patrick Palka wrote:
>
> On Sun, Jan 7, 2024 at 3:33 PM Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> Ping.
Huh, I thought I'd already approved this ... sorry.
OK for trunk, with the -ftemplate-depth test change too.
Hi Kito!
On Thu, 11 Jan 2024 17:06:09 +0800
Kito Cheng wrote:
> Try to list all supported extensions: name, version and few description
> for each extension.
>
> gcc/ChangeLog:
>
> * doc/invoke.texi (RISC-V Options): Add list of supported
> extensions.
> ---
> gcc/doc/invoke.texi
On 1/3/24 15:06, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
OK.
-- >8 --
Since partial template specializations can't be named directly, access
control (when declared at class scope) doesn't apply to them, so we
shouldn't have to set
On 1/3/24 13:49, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk and perhaps 13?
OK for both.
-- >8 --
Here we neglect to emit the definitions of A::f2 and A::f4
despite the explicit instantiations ultimately because TREE_PUBLIC isn't
set
On Wed, Jan 3, 2024 at 3:06 PM Patrick Palka wrote:
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk?
Ping.
>
> -- >8 --
>
> Since partial template specializations can't be named directly, access
> control (when declared at class scope) doesn't apply to them,
On Wed, Jan 3, 2024 at 1:49 PM Patrick Palka wrote:
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> for trunk and perhaps 13?
Ping.
>
> -- >8 --
>
> Here we neglect to emit the definitions of A::f2 and A::f4
> despite the explicit instantiations ultimately because
On Fri, Jan 5, 2024 at 11:50 AM Patrick Palka wrote:
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> for trunk and perhaps 13?
Ping.
>
> -- >8 --
>
> invalid_tparm_referent_p was rejecting using the address of a class NTTP
> object as a template argument, but this
On Mon, Jan 8, 2024 at 1:40 PM Patrick Palka wrote:
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk/13/12?
Ping.
>
> -- >8 --
>
> The get_target_expr call added in r12-7069-g119cea98f66476 causes us
> for the below testcase to call build_vec_delete in a
On Sun, Jan 7, 2024 at 3:33 PM Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
Ping.
>
> -- >8 --
>
> The recursively defined constraints on _Variadic_union's user-defined
> destructor (necessary for maintaining trivial destructibility of the
> variant iff
--save-temps is needed to scan assembly outputs for assemble, link and
run tests. Not all compile tests need --save-temps unless they used to
trigger GCC bugs. Run --save-temps from compile tests if not needed.
PR testsuite/113369
* g++.dg/abi/ref-temp1.C: Remove --save-temps.
On Mon, 15 Jan 2024 at 18:50, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13?
OK for both, thanks.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/stl_iterator.h (const_iterator): Define
> conversion operators as per P2836R1.
> *
On Mon, 15 Jan 2024 at 16:51, Jonathan Wakely wrote:
>
> On Mon, 15 Jan 2024 at 16:27, Patrick Palka wrote:
> >
> > On Sat, 13 Jan 2024, Jonathan Wakely wrote:
> >
> > > On Sat, 13 Jan 2024 at 00:06, Patrick Palka wrote:
> > > >
> > > > On Fri, 12 Jan 2024, Jonathan Wakely wrote:
> > > >
> > >
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13?
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (const_iterator): Define
conversion operators as per P2836R1.
* include/bits/version.def (ranges_as_const): Update value.
* include/bits/version.h:
On 1/15/24 07:56, Maxim Kuvyrkov wrote:
Hi Vladimir,
Hi Jeff,
Richard and Alexander have reviewed this patch and [I assume] have no
further comments. OK to merge?
I trust Richard and Alexander therefore I did not do additional review
of the patches and have no any comment. Richard's or
Some more info:
On 2024-01-14 21:39, Julia DeMille wrote:
I've gotten this to work, and run into an unexpected situation.
Something about the personality routine is causing a SIGABRT.
Investigating further.
This occurs due to an assertion in _Unwind_SetGR. Seemingly, the
compiler intrinsic
Wrong attachment, sorry.
v4-0001-Ifdef-.hidden-.type-and-.size-pseudo-ops-for-aarc.patch
Description: v4-0001-Ifdef-.hidden-.type-and-.size-pseudo-ops-for-aarc.patch
Tested x86_64-linux. Pushed to trunk.
-- >8 --
There's an error for -fconcepts-ts due to using a concept where a bool
NTTP is required, which is fixed by using the vraiable template that
already exists in the class scope.
This doesn't fix the problem with -fconcepts-ts as changes to the
On Sat, 13 Jan 2024 at 11:18, Jonathan Wakely wrote:
>
> On Fri, 12 Jan 2024 at 22:59, Jonathan Wakely wrote:
> >
> > It would be good to update the bundled tzdata for GCC 14.1 and 13.3
>
> The expiry date for the hardcoded leapseconds list should be updated
> too, as there's a new date in the
On Mon, 15 Jan 2024 at 16:27, Patrick Palka wrote:
>
> On Sat, 13 Jan 2024, Jonathan Wakely wrote:
>
> > On Sat, 13 Jan 2024 at 00:06, Patrick Palka wrote:
> > >
> > > On Fri, 12 Jan 2024, Jonathan Wakely wrote:
> > >
> > > > On Fri, 12 Jan 2024 at 18:33, Patrick Palka wrote:
> > > > >
> > > >
> On Jan 15, 2024, at 3:13 AM, Eric Botcazou wrote:
>
>> Okay, so, the "unsharing everything” is done automatically by the compiler
>> before gimplification?
>
> See the blurb at gimplify.cc:835 and below about this.
Thanks a lot for the info. (I read this paragraph before sending the
> On Jan 15, 2024, at 10:06 AM, Jakub Jelinek wrote:
>
> On Mon, Jan 15, 2024 at 02:54:26PM +, Qing Zhao wrote:
>> So, before gimplification, when inserting tree node, we don’t need manually
>> add unshare_expr since the gimplification will automatically unshare nodes.
>
> There are
Hi!
The ICE on this testcase was fixed by r14-7141.
Tested on x86_64-linux -m32/-m64 with current trunk as well as older
trunk which still ICEd, committed to trunk as obvious.
2024-01-15 Jakub Jelinek
PR rtl-optimization/113048
* gcc.target/i386/pr113048.c: New test.
---
On Sat, 13 Jan 2024, Jonathan Wakely wrote:
> On Sat, 13 Jan 2024 at 00:06, Patrick Palka wrote:
> >
> > On Fri, 12 Jan 2024, Jonathan Wakely wrote:
> >
> > > On Fri, 12 Jan 2024 at 18:33, Patrick Palka wrote:
> > > >
> > > > On Fri, 12 Jan 2024, Jonathan Wakely wrote:
> > > >
> > > > > On Fri,
Option -mskip-bug is no more missing from the documentation.
Johann
--
AVR: Document option -mskip-bug.
gcc/
* doc/invoke.texi (AVR Options) [-mskip-bug]: Add documentation.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 1773f0d3f0c..01170c0ce5c 100644
---
Hello Richard.
Thank you for your suggestion. I am sending a patch update according to it.
> How about avoiding the clash by using the names HIDDEN, SYMBOL_TYPE and
> SYMBOL_SIZE, with SYMBOL_TYPE taking the symbol type as argument?
Yes, unless the symbol is explicitly exported using
On Mon, Jan 15, 2024 at 4:35 PM Kito Cheng wrote:
>
> Ok :)
I've re-created changelog entries in commit messages (commit hook
rejected the commits)
and pushed.
Thanks,
Christoph
>
>
> Christoph Müllner 於 2024年1月15日 週一 23:17 寫道：
>>
>> On Mon, Jan 15, 2024 at 9:35 AM Liao Shihua wrote:
>> >
On 13/01/2024 15:46, Alex Coplan wrote:
> As the PR shows (specifically #c7) we are missing updating uses of mem
> when inserting an stp in the aarch64 load/store pair fusion pass. This
> patch fixes that.
>
> RTL-SSA has a simple view of memory and by default doesn't allow stores
> to be
Ok :)
Christoph Müllner 於 2024年1月15日 週一 23:17 寫道：
> On Mon, Jan 15, 2024 at 9:35 AM Liao Shihua wrote:
> >
> > Update v3 -> v4:
> > 1.Typo fix.
> > 2.Only test *intrinsic-32 on rv32 and *intrinsic-64 on rv64.
> > 3.Update Copyright year to 2024.
>
> Thanks, for fixing the rv32/rv64
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113354
The patch was tested on building MIPS target.
The patch was successfully tested and bootstrapped on x86-64, ppc64le,
aarch64.
commit 5f662bce28618ea5417f68a17d5c2d34b052ecb2
Author: Vladimir N. Makarov
Date:
I gave it another shot now by introducing a separate function as
Richard suggested. It's probably not at the location he intended.
The way I read the discussion there hasn't been any consensus
on how (or rather where) to properly tackle the problem. Any
other ideas still?
Regards
Robin
On Mon, Jan 15, 2024 at 9:35 AM Liao Shihua wrote:
>
> Update v3 -> v4:
> 1.Typo fix.
> 2.Only test *intrinsic-32 on rv32 and *intrinsic-64 on rv64.
> 3.Update Copyright year to 2024.
Thanks, for fixing the rv32/rv64 issues!
I've tested this series: no regressions and all new tests pass.
On Mon, Jan 15, 2024 at 02:54:26PM +, Qing Zhao wrote:
> So, before gimplification, when inserting tree node, we don’t need manually
> add unshare_expr since the gimplification will automatically unshare nodes.
There are cases where unshare_expr is needed even then, such as the uses in
the
> On Jan 15, 2024, at 4:31 AM, Richard Biener
> wrote:
>
> On Fri, Jan 12, 2024 at 6:30 PM Qing Zhao wrote:
>>
>> Thanks a lot for the reply.
>>
>>> On Jan 12, 2024, at 11:28 AM, Richard Biener
>>> wrote:
>>>
>>>
>>>
Am 12.01.2024 um 16:55 schrieb Qing Zhao :
Hi,
Hi,
For the testcase in the PR, we try to pair insns where the first has
writeback and the second uses the updated base register. This causes us
to record a hazard against the second insn, thus narrowing the move
range away from the end of the BB.
However, it isn't meaningful to record hazards
The following adjusts find_base_value similar as to what
find_base_term was adjusted for PR113255.
* alias.cc (known_base_value_p): Remove.
(find_base_value): Remove PLUS/MINUS handling
when both operands are not CONST_INT_P.
---
gcc/alias.cc | 62
When the x86 backend generates code for cpymem with the rep_8byte
strathegy for the 8 byte aligned main rep movq it needs to compute
an adjusted pointer to the source after doing a prologue aligning
the destination. It computes that via
src_ptr + (dest_ptr - orig_dest_ptr)
which is perfectly
Dear scheduler maintainers,
Gentle ping. This patch improves debugging output, it does not touch
scheduling logic.
On Wed, 22 Nov 2023 at 15:15, Maxim Kuvyrkov
wrote:
> Scheduler dependency analysis uses two main data structures:
> 1. reg_pending_* data contains effects of INSN on the
Dear scheduler maintainers,
Gentle ping. This patch improves debugging output, it does not touch
scheduling logic.
On Wed, 22 Nov 2023 at 15:15, Maxim Kuvyrkov
wrote:
> Scheduler dependency analysis uses two main data structures:
> 1. reg_pending_* data contains effects of INSN on the
Dear scheduler maintainers,
Gentle ping. This is a trivial cleanup.
On Wed, 22 Nov 2023 at 15:14, Maxim Kuvyrkov
wrote:
> gcc/ChangeLog:
>
> * sched-deps.cc (init_deps, init_deps_reg_last): Simplify.
> (free_deps): Remove useless code.
> ---
> gcc/sched-deps.cc | 13
Dear scheduler maintainers,
Gentle ping. This is a trivial patch, which makes debugging sched-deps.cc
slightly more enjoyable.
On Wed, 22 Nov 2023 at 15:14, Maxim Kuvyrkov
wrote:
> gcc/ChangeLog:
>
> * sched-deps.cc (sd_add_dep, find_inc): Add logging about
> dependency
Dear scheduler maintainers,
Gentle ping. This patch is borderline trivial and affects only the lucky
few who debug sched-deps.cc code. OK to merge?
On Wed, 22 Nov 2023 at 15:14, Maxim Kuvyrkov
wrote:
> Better propagate flags from dump_lists() into dump_dep() and
> add a missing "]" in
Dear RTL maintainers,
Gently ping. This patch adds a couple of new functions to lists.cc, which
then are used to simplify logic in the scheduler. OK to merge?
On Wed, 22 Nov 2023 at 15:14, Maxim Kuvyrkov
wrote:
> This patch simplifies logic behind deps_join(), which will be
> important for
Hi Vladimir,
Hi Jeff,
Richard and Alexander have reviewed this patch and [I assume] have no
further comments. OK to merge?
On Wed, 22 Nov 2023 at 15:14, Maxim Kuvyrkov
wrote:
> This patch avoids sched-deps.cc:find_inc() creating exponential number
> of dependencies, which become memory and
On 15/01/24 6:14 pm, Ajit Agarwal wrote:
> Hello Richard:
>
> On 15/01/24 3:03 pm, Richard Biener wrote:
>> On Sun, Jan 14, 2024 at 4:29 PM Ajit Agarwal wrote:
>>>
>>> Hello All:
>>>
>>> This patch add the vecload pass to replace adjacent memory accesses lxv
>>> with lxvp
>>> instructions.
Hello Richard:
On 15/01/24 3:03 pm, Richard Biener wrote:
> On Sun, Jan 14, 2024 at 4:29 PM Ajit Agarwal wrote:
>>
>> Hello All:
>>
>> This patch add the vecload pass to replace adjacent memory accesses lxv with
>> lxvp
>> instructions. This pass is added before ira pass.
>>
>> vecload pass
On Mon, Jan 15, 2024 at 12:27 PM Andrew Carlotti
wrote:
>
> This allows code to determine why a particular function is
> multiversioned. For now, this will primarily be used to preserve
> existing name mangling quirks when subsequent commits change all
> function multiversioning name mangling to
This patch fixes -70% performance drop from GCC-13.2 to GCC-14 with
-march=rv64gcv in real hardware.
The root cause is incorrect cost model cause inefficient vectorization which
makes us performance drop significantly.
So this patch does:
1. Adjust vector to scalar cost by introducing v to
Rebase in v3: Rebase to the trunk and commit it as it's approved by Robin.
Update in v2: Add dynmaic lmul test.
This patch fixes the regression between GCC 13.2.0 and trunk GCC (GCC-14)
GCC 13.2.0:
lui a5,%hi(a)
li a4,19
sb a4,%lo(a)(a5)
li
These tests are not intended to designate "correct" behaviour, but are
instead intended to demonstrate current behaviour, and provide a warning
if subsequent patches might lead to compatibility issues for targets
with existing function multiversioning support.
gcc/testsuite/ChangeLog:
*
There's no functional change here, but it makes it clearer that all
three locations should be doing the same thing (aside from changes to
flag_abi_version).
gcc/cp/ChangeLog:
* mangle.cc (mangle_decl): Consistently use get_mangled_id.
diff --git a/gcc/cp/mangle.cc b/gcc/cp/mangle.cc
This patch series should have no functional change besides the mangling of some
symbol names on AArch64.
Patch 1/5 adds lots of tests to verify that existing mangling behaviour on x86
and PowerPC is unchanged.
Patch 2/5 extends DECL_FUNCTION_VERSIONED to a 2-bit enum.
Patches 3/5 and 4/5 are
The following avoids splitting an edge before redirecting it. This
allows the loop father of the new block to be correct in the first
place.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/113385
* tree-vect-loop-manip.cc
When using "target" or "target_version" attributes, some parts of the
code assume that the default version has no function-specific mangling
while generating names for the resolver and ifunc. Since aarch64 now
breaks that assumption, we add an explicit workaround for this issue.
Ideally we'd
The new name better describes where it is used, and will be more
suitable when subsequent commits make further changes to this function.
gcc/ChangeLog:
* cgraph.h (create_version_clone_with_body): Rename parameter
and change default value.
* cgraphclones.cc: Rename
This allows code to determine why a particular function is
multiversioned. For now, this will primarily be used to preserve
existing name mangling quirks when subsequent commits change all
function multiversioning name mangling to use explicit target hooks.
However, this can also be used in
LGTM.
Regards
Robin
OK, thanks.
Regards
Robin
LGTM. I think removing riscv_vector_abi can be another separate followup patch.
But plz make sure you have passed the regression before committed.
Thanks.
juzhe.zh...@rivai.ai
From: yanzhang.wang
Date: 2024-01-15 14:00
To: gcc-patches
CC: juzhe.zhong; kito.cheng; pan2.li; lehua.ding;
Add more dump check to robostify the tests.
Committed.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vls/reduc-1.c: Add dump check.
* gcc.target/riscv/rvv/autovec/vls/reduc-10.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/reduc-11.c: Ditto.
*
I went ahead and installed Andrew's patch
https://gcc.gnu.org/r14-7240
Johann
Am 15.01.24 um 00:19 schrieb Levente via Gcc-help:
I'm trying to set up a toolchain for avr-dd MCUs, and I get this error
message when I try to compile gcc:
Lev
--
Author: Andrew Pinski
Date: Mon Jan 15
While working on another bug, I noticed the ENABLE_SCOPE_CHECKING macro
and thought to try it out. It caused selftest to ICE. This patch is a
minimal fix to get it working again.
Probably this should use a test to stop this regressing again in the
future the next time new scope-kinds are added,
1 - 100 of 114 matches
Mail list logo
