RTL expansion of substitution to [DS]Cmode hard register includes obstructive
register clobber.
A simplest example:
double _Complex test(double _Complex c) {
return c;
}
will be converted to:
(set (reg:DF 42 [ c ]) (reg:DF 2 a2))
(set (reg:DF 43 [ c+8 ]) (reg:DF 4 a4))
When spilled DFmode registers are reloaded in, once loaded into a pair of
SImode regs and then copied from that regs. Such unwanted reg-reg moves
seems not to be eliminated at the "cprop_hardreg" stage, despite no problem
in output reloads.
Luckily it is easy to resolve such inefficiencies, with
This patch introduces support for sibling call optimization, when call0
ABI is in effect.
gcc/ChangeLog:
* config/xtensa/xtensa-protos.h (xtensa_prepare_expand_call,
xtensa_emit_sibcall): New prototypes.
(xtensa_expand_epilogue): Add new argument that specifies whether
This patch offers better RTL representations against straightforward
derivations from some tree optimizers' canonicalized forms.
- rounding up to even, such as '(x + (x & 1))', is canonicalized to
'((x + 1) & -2)', but the former is one instruction less than the latter
in Xtensa ISA.
- signed
gcc/ChangeLog:
* doc/invoke.texi: Document -mextra-l32r-costs= option.
---
gcc/doc/invoke.texi | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index b6c0305f198..2a3c638de40 100644
--- a/gcc/doc/invoke.texi
+++
On Mon, 2022-06-13 at 20:45 -0400, Aldy Hernandez wrote:
> Final implies we can't further derive from the derived class, right?
"final" on a vfunc implies that nothing overrides that vfunc, but you
could still have further derived classes.
You can think of it as "nothing further overrides this
Final implies we can't further derive from the derived class, right? If so
we may want just override.
Andrew, what are your thoughts?
Thanks for doing this.
Aldy
On Mon, Jun 13, 2022, 14:28 David Malcolm wrote:
> Ping re this patch:
>
On Mon, Jun 13, 2022 at 9:39 AM Takayuki 'January June' Suwa
wrote:
>
> On 2022/06/13 12:49, Max Filippov wrote:
> > Hi Suwa-san,
> hi!
>
> > This change produces a bunch of regression test failures in big-endian
> > configuration:
> bad news X(
> that point is what i was a little worried
On Sat, Jun 11, 2022 at 11:43 PM Takayuki 'January June' Suwa
wrote:
>
> In Xtensa ISA, there is no single machine instruction that calculates unary
> bitwise negation, but a few similar fused instructions are exist:
>
>"BALL Ax, Ay, label" // if ((~Ax & Ay) == 0) goto label;
>"BNALL
On Sat, Jun 11, 2022 at 11:43 PM Takayuki 'January June' Suwa
wrote:
>
> No need to describe the "false side" conditional insn patterns anymore.
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa-protos.h (xtensa_emit_branch):
> Remove the first argument.
>
On Mon, Jun 13, 2022 at 9:39 AM Takayuki 'January June' Suwa
wrote:
>
> Changes from v1:
> (*shift_per_byte_omit_AND_1): changed to be split as early as possible
>
>
> ===
> This patch introduces funnel shifter utilization, and rearranges existing
> "per-byte shift" insn patterns.
>
>
Pinging this item:
https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593473.html
Thanks.
Excerpts from Rainer Orth's message of Juni 13, 2022 8:58 pm:
> Hi Iain,
>
>> This patches merges the D front-end with upstream dmd 821ed393d, and the
>> standard library with upstream druntime 454471d8 and phobos 1206fc94f.
>
>> libphobos/ChangeLog:
>>
>> * libdruntime/MERGE: Merge
On Thu, 9 Jun 2022, Kito Cheng wrote:
> LGTM, *f_quiet4_default and
> *f_quiet4_snan has set their own
> length and the only user of this setting is
> *cstore4, but apparently the length if 4 for that
> not 8.
I have committed this change now, thank you for your review.
Maciej
On Mon, Jun 13, 2022 at 03:38:23PM -0400, Jason Merrill via Gcc-patches wrote:
> I noticed that -fsanitize=undefined -fsanitize-undefined-trap-on-error was
> omitting the usual -Wreturn-type warning for control flowing off the end of
> a function. This was because the warning code was looking for
When not optimizing, we can't do anything useful with unreachability in
terms of code performance, so we might as well improve debugging by turning
__builtin_unreachable into a trap. In the PR richi suggested introducing an
-funreachable-traps flag for this, but this functionality is already
I noticed that -fsanitize=undefined -fsanitize-undefined-trap-on-error was
omitting the usual -Wreturn-type warning for control flowing off the end of
a function. This was because the warning code was looking for calls either
to __builtin_unreachable or the UBSan function, but these flags produce
On Fri, 10 Jun 2022 at 22:42, Mark Mentovai wrote:
>
> Thanks, Jonathan. I am, in fact, so certifying.
Great, thanks.
>
> I do believe that bringing up support for new OS versions is in scope for
> open branches, and it makes sense to merge, particularly for a trivial and
> uncontentious patch
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This is LWG 3220 which is about to become Tentatively Ready.
libstdc++-v3/ChangeLog:
* include/std/atomic (__atomic_val_t): Use __type_identity_t
instead of atomic::value_type, as per LWG 3220.
*
Hi Iain,
> This patches merges the D front-end with upstream dmd 821ed393d, and the
> standard library with upstream druntime 454471d8 and phobos 1206fc94f.
> libphobos/ChangeLog:
>
> * libdruntime/MERGE: Merge upstream druntime 454471d8.
> * libdruntime/Makefile.am
Ping re this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595443.html
OK for trunk?
Thanks
Dave
On Mon, 2022-05-23 at 15:28 -0400, David Malcolm wrote:
> gcc/cp/ChangeLog:
> * cxx-pretty-print.h: Add "final" and "override" to various
> vfunc
> implementations,
Ping for this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595440.html
OK for trunk?
Thanks
Dave
On Mon, 2022-05-23 at 15:28 -0400, David Malcolm wrote:
> gcc/ChangeLog:
> * config/i386/i386-features.h: Add "final" and "override" to
> scalar_chain vfunc
Ping re this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595438.html
OK for trunk?
Thanks
Dave
On Mon, 2022-05-23 at 15:28 -0400, David Malcolm wrote:
> gcc/ChangeLog:
> * value-relation.h: Add "final" and "override" to
> relation_oracle
> vfunc implementations
Ping for this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595435.html
OK for trunk?
Thanks
Dave
On Mon, 2022-05-23 at 15:28 -0400, David Malcolm wrote:
> gcc/ChangeLog:
> * tree-switch-conversion.h: Add "final" and "override" to
> cluster
> vfunc implementations
Ping on this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595434.html
OK for trunk?
Thanks
Dave
On Mon, 2022-05-23 at 15:28 -0400, David Malcolm wrote:
> gcc/ChangeLog:
> * expr.cc: Add "final" and "override" to op_by_pieces_d vfunc
> implementations as
Ping for this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595436.html
OK for tunk?
Thanks
Dave
On Mon, 2022-05-23 at 15:28 -0400, David Malcolm wrote:
> gcc/ChangeLog:
> * compare-elim.cc: Add "final" and "override" to dom_walker
> vfunc
> implementations,
On 6/13/2022 4:19 AM, Tamar Christina wrote:
-Original Message-
From: Gcc-patches On Behalf Of Jeff Law via
Gcc-patches
Sent: Sunday, June 12, 2022 6:27 PM
To: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH]middle-end Use subregs to expand COMPLEX_EXPR to
set the lowpart.
On 6/9/2022
On 6/13/2022 5:54 AM, Richard Biener wrote:
On Sun, Jun 12, 2022 at 7:27 PM Jeff Law via Gcc-patches
wrote:
[...]
On a related topic, any thoughts on keeping complex objects as complex
types/modes through gimple and into at least parts of the RTL pipeline?
The way complex arithmetic
Changes from v1:
(*shift_per_byte_omit_AND_1): changed to be split as early as possible
===
This patch introduces funnel shifter utilization, and rearranges existing
"per-byte shift" insn patterns.
gcc/ChangeLog:
* config/xtensa/predicates.md (logical_shift_operator,
On 2022/06/13 12:49, Max Filippov wrote:
> Hi Suwa-san,
hi!
> This change produces a bunch of regression test failures in big-endian
> configuration:
bad news X(
that point is what i was a little worried about...
> E.g. for the test gcc.c-torture/execute/struct-ini-2.c
> the following assembly
> Am 13.06.2022 um 16:36 schrieb H.J. Lu :
>
> On Mon, Jun 13, 2022 at 3:11 AM Richard Biener
> wrote:
>>
>>> On Tue, Jun 7, 2022 at 9:02 PM H.J. Lu via Gcc-patches
>>> wrote:
>>>
>>> Add -fextra-libc-function=memcmpeq to map
>>>
>>> extern int __memcmpeq (const void *, const void *,
On 6/13/22 05:15, Richard Biener wrote:
On Fri, Jun 10, 2022 at 12:58 PM Eric Botcazou via Gcc-patches
wrote:
Hi,
gimple_set_location is mostly invoked on newly built GIMPLE statements, so
their location is UNKNOWN_LOCATION and setting it will clobber the warning
data of the passed location,
Under certain conditions register_operand predicate also allows
subregs of memory operands. When RTL checking is enabled, these
will fail with REGNO (op).
Allow subregs of memory operands, these are guaranteed
to be reloaded to a register.
2022-06-13 Uroš Bizjak
gcc/ChangeLog:
PR
This patch changes the `Compiler::onParseModule' hook in the D front-end
to scan for declarations of recognised gcc built-ins from any module.
Previously, only the `core.stdc' package was scanned.
In addition to matching of the symbol, any user-applied `@attributes' or
`pragma(mangle)' name will
> -Original Message-
> From: Richard Biener
> Sent: Monday, June 13, 2022 12:48 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Sandiford
>
> Subject: RE: [PATCH 1/2]middle-end Support optimized division by pow2
> bitmask
>
> On Mon, 13 Jun 2022, Tamar Christina
On Mon, Jun 13, 2022 at 3:11 AM Richard Biener
wrote:
>
> On Tue, Jun 7, 2022 at 9:02 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > Add -fextra-libc-function=memcmpeq to map
> >
> > extern int __memcmpeq (const void *, const void *, size_t);
> >
> > which was added to GLIBC 2.35, to
On aarch64, --with-arch, --with-cpu and --with-tune only have an
effect on the driver, so “./xgcc -B./ -O3” can give significantly
different results from “./cc1 -O3”. --with-arch did have a limited
effect on ./cc1 in previous releases, although it didn't work
entirely correctly.
Being of a lazy
On Mon, Jun 13, 2022 at 7:02 AM Richard Biener
wrote:
>
> On Thu, Jun 2, 2022 at 5:54 PM Eric Gallager via Gcc-patches
> wrote:
> >
> > So, I'm working on fixing PR bootstrap/44425, and have this patch to
> > have the top-level configure script check in the value passed to
> > `--prefix=` when
On Mon, Jun 13, 2022 at 09:29:34PM +0800, Chung-Lin Tang wrote:
> > I was hoping you'd drop all this.
> > Seehttps://gcc.gnu.org/r13-1002
> > for implementation (both C and C++ FE) of something very similar,
> > the only difference there is that in the case of linear clause, it is
> > looking for
On 2022/6/9 8:22 PM, Jakub Jelinek wrote:
+ OpenMP 5.2:
+
+ uses_allocators ( modifier : allocator-list )
Please drop the -list above.
+ uses_allocators ( modifier , modifier : allocator-list )
and here too.
Thanks for catching.
+ struct item_tok
+ {
+location_t loc;
+
From: Christoph Müllner
The current description of RISCV_CORE() does not match the
implementation. This commit provides a fix for that.
gcc/ChangeLog:
* config/riscv/riscv-cores.def: Fix comment.
Signed-off-by: Christoph Müllner
---
gcc/config/riscv/riscv-cores.def | 12 +---
From: Christoph Müllner
This adds Allwinner's D1 to the list of known cores.
The Allwinner includes a single-core XuanTie C906 and is available
for quite some time. Note, that the tuning struct for the C906
is already part of GCC.
gcc/ChangeLog:
* config/riscv/riscv-cores.def
Hi,
The existing TypeInfo errors can be cryptic. This patch alters the
diagnostic to include which expression is requiring `object.TypeInfo'.
Bootstrapped and regression tested on x86_64-linux-gnu, and backported
to releases/gcc-12 branch.
Regards,
Iain.
---
gcc/d/ChangeLog:
*
Hi!
OpenMP 5.2 changed once more what device numbers are allowed.
In 5.1, valid device numbers were [0, omp_get_num_devices()].
5.2 makes also -1 valid (calls it omp_initial_device), which is equivalent
in behavior to omp_get_num_devices() number but has the advantage that it
is a constant. And
On Sun, Jun 12, 2022 at 7:27 PM Jeff Law via Gcc-patches
wrote:
[...]
> On a related topic, any thoughts on keeping complex objects as complex
> types/modes through gimple and into at least parts of the RTL pipeline?
>
> The way complex arithmetic instructions work on our chip is going to be
>
On Mon, 13 Jun 2022, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Monday, June 13, 2022 9:38 AM
> > To: Richard Sandiford
> > Cc: Tamar Christina ; gcc-patches@gcc.gnu.org;
> > nd ; Richard Earnshaw ;
> > Marcus Shawcroft ; Kyrylo Tkachov
> > ;
On Mon, 13 Jun 2022, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Monday, June 13, 2022 10:39 AM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; Richard Sandiford
> >
> > Subject: Re: [PATCH 1/2]middle-end Support optimized division by
On Mon, Jun 13, 2022 at 12:02 PM Kewen.Lin wrote:
>
> Hi,
>
> As PR105940 shown, when rs6000 port tries to assign
> m_suggested_unroll_factor by 4 or so, there will be ICE
> on below statement:
>
> exact_div (LOOP_VINFO_VECT_FACTOR (loop_vinfo),
>
> + /* If tem is a VAR_DECL, we need a memory reference. */
> + enum expand_modifier tem_modifier = modifier;
> + if (tem_modifier == EXPAND_SUM)
> + tem_modifier = EXPAND_NORMAL;
> + if (TREE_CODE (tem) == VAR_DECL)
> + tem_modifier = EXPAND_MEMORY;
>
>
On Mon, Jun 13, 2022 at 11:46 AM Eric Botcazou wrote:
>
> > So that also applies to
> >
> > "... and the second profiling function is called before the exit
> > +corresponding to this first entry"
> >
> > specifically "corresponding to this first entry"? As if the second
> > entry exits first
This moves some module writing into a newly added write_end function,
which is called after writing initializers.
Thus paving the way to eliminate calls to NOP initializer fns.
nathan
--
Nathan SidwellFrom 6303eee4b92e8509409503a3abebde8bd50f0f05 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
On Fri, Jun 10, 2022 at 12:58 PM Eric Botcazou via Gcc-patches
wrote:
>
> Hi,
>
> gimple_set_location is mostly invoked on newly built GIMPLE statements, so
> their location is UNKNOWN_LOCATION and setting it will clobber the warning
> data of the passed location, if any.
Hmm, I think instead of
Hi,
This patches merges the D front-end with upstream dmd 821ed393d, and the
standard library with upstream druntime 454471d8 and phobos 1206fc94f.
D front-end changes:
- Import latest bug fixes to mainline.
D runtime changes:
- Fix duplicate Elf64_Dyn definitions on Solaris.
-
On Thu, Jun 2, 2022 at 5:54 PM Eric Gallager via Gcc-patches
wrote:
>
> So, I'm working on fixing PR bootstrap/44425, and have this patch to
> have the top-level configure script check in the value passed to
> `--prefix=` when looking for gmp/mpfr/mpc. It "works" (in that
> configuring with just
On Tue, Jun 7, 2022 at 7:24 PM Andrew Carlotti via Gcc-patches
wrote:
>
> Hi all,
>
> This lowers vcombine intrinsics to a GIMPLE vector constructor, which enables
> better optimisation during GIMPLE passes.
>
> Bootstrapped and tested on aarch64-none-linux-gnu, and tested for
>
On Wed, Jun 8, 2022 at 4:14 PM Eric Botcazou via Gcc-patches
wrote:
>
> > The fix is to ensure that we call expand_expr with EXPAND_MEMORY
> > when processing the VAR_DECL's returned by get_inner_reference.
> >
> > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> > and make
> -Original Message-
> From: Gcc-patches bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of Jeff Law via
> Gcc-patches
> Sent: Sunday, June 12, 2022 6:27 PM
> To: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH]middle-end Use subregs to expand COMPLEX_EXPR to
> set the lowpart.
>
>
On Tue, Jun 7, 2022 at 11:44 PM David Faust via Gcc-patches
wrote:
OK
> gcc/
>
> * dwarf2out.cc (dw_get_die_parent): New function.
> * dwarf2out.h (dw_get_die_parent): Declare it here.
> ---
> gcc/dwarf2out.cc | 8
> gcc/dwarf2out.h | 1 +
> 2 files changed, 9
On Tue, Jun 7, 2022 at 9:02 PM H.J. Lu via Gcc-patches
wrote:
>
> Add -fextra-libc-function=memcmpeq to map
>
> extern int __memcmpeq (const void *, const void *, size_t);
>
> which was added to GLIBC 2.35, to __builtin_memcmp_eq.
Humm. Can't we instead use the presence of a declaration
of
> -Original Message-
> From: Richard Biener
> Sent: Monday, June 13, 2022 10:39 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Sandiford
>
> Subject: Re: [PATCH 1/2]middle-end Support optimized division by pow2
> bitmask
>
> On Mon, 13 Jun 2022, Richard Biener
Hi,
As PR105940 shown, when rs6000 port tries to assign
m_suggested_unroll_factor by 4 or so, there will be ICE
on below statement:
exact_div (LOOP_VINFO_VECT_FACTOR (loop_vinfo),
loop_vinfo->suggested_unroll_factor);
In function vect_analyze_loop_2, the current place of
On Mon, Jun 6, 2022 at 11:06 AM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Sat, May 21, 2022 at 5:31 PM Roger Sayle
> > wrote:
> >> This patch simplifies vec_unpack_hi_expr/vec_unpack_lo_expr of a uniform
> >> constructor or vec_duplicate operand. The motivation is from PR
> -Original Message-
> From: Richard Biener
> Sent: Monday, June 13, 2022 9:38 AM
> To: Richard Sandiford
> Cc: Tamar Christina ; gcc-patches@gcc.gnu.org;
> nd ; Richard Earnshaw ;
> Marcus Shawcroft ; Kyrylo Tkachov
> ; ro...@eyesopen.com
> Subject: Re: [PATCH]AArch64 relax predicate on
> So that also applies to
>
> "... and the second profiling function is called before the exit
> +corresponding to this first entry"
>
> specifically "corresponding to this first entry"? As if the second
> entry exits first will that call the second profiling function or will
> it really be
On Fri, Jun 3, 2022 at 9:31 AM Aldy Hernandez wrote:
>
> [I have conservatively assumed that both the loop-ch and loop-unswitch
> passes, which also use the ranger, only support integers and pointers.
> If the goal is to handle other types as well, irange::supports_p()
> should be
On Mon, 13 Jun 2022, Richard Biener wrote:
> On Thu, 9 Jun 2022, Tamar Christina wrote:
>
> > Hi All,
> >
> > In plenty of image and video processing code it's common to modify pixel
> > values
> > by a widening operation and then scale them back into range by dividing by
> > 255.
> >
> >
On Thu, 9 Jun 2022, Tamar Christina wrote:
> Hi All,
>
> In plenty of image and video processing code it's common to modify pixel
> values
> by a widening operation and then scale them back into range by dividing by
> 255.
>
> This patch adds an optab to allow us to emit an optimized sequence
On Tue, 7 Jun 2022, Richard Sandiford wrote:
> Joel Hutton writes:
> >> > Patches attached. They already incorporated the .cc rename, now
> >> > rebased to be after the change to tree.h
> >>
> >> @@ -1412,8 +1412,7 @@ vect_recog_widen_op_pattern (vec_info *vinfo,
> >>2,
On Tue, 7 Jun 2022, Joel Hutton wrote:
> Thanks Richard,
>
> > I thought the potential problem with the above is that gimple_build is a
> > folding interface, so in principle it's allowed to return an existing
> > SSA_NAME
> > set by an existing statement (or even a constant).
> > I think in
Tamar Christina writes:
> Hi All,
>
> When lowering COMPLEX_EXPR we currently emit two VEC_EXTRACTs. One for the
> lowpart and one for the highpart.
>
> The problem with this is that in RTL the lvalue of the RTX is the only thing
> tying the two instructions together.
>
> This means that e.g.
On Mon, 13 Jun 2022, Richard Sandiford wrote:
> Richard Biener writes:
> > On Wed, 8 Jun 2022, Richard Sandiford wrote:
> >> Tamar Christina writes:
> >> >> -Original Message-
> >> >> From: Richard Sandiford
> >> >> Sent: Wednesday, June 8, 2022 11:31 AM
> >> >> To: Tamar Christina
>
Richard Biener writes:
> On Wed, 8 Jun 2022, Richard Sandiford wrote:
>> Tamar Christina writes:
>> >> -Original Message-
>> >> From: Richard Sandiford
>> >> Sent: Wednesday, June 8, 2022 11:31 AM
>> >> To: Tamar Christina
>> >> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> >>
On Wed, 8 Jun 2022, Richard Sandiford wrote:
> Tamar Christina writes:
> >> -Original Message-
> >> From: Richard Sandiford
> >> Sent: Wednesday, June 8, 2022 11:31 AM
> >> To: Tamar Christina
> >> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> >> ; Marcus Shawcroft
> >> ; Kyrylo
On Sat, Jun 11, 2022 at 1:46 AM H.J. Lu wrote:
>
> On Fri, Jun 10, 2022 at 7:44 AM H.J. Lu wrote:
> >
> > On Fri, Jun 10, 2022 at 2:38 AM Florian Weimer wrote:
> > >
> > > * liuhongt via Libc-alpha:
> > >
> > > > +\subsubsection{Special Types}
> > > > +
> > > > +The \code{__Bfloat16} type uses
74 matches
Mail list logo
