> On Jul 30, 2024, at 6:17 AM, Richard Biener wrote:
>
> The following adds a target hook to specify whether regs of MODE can be
> used to transfer bits. The hook is supposed to be used for value-numbering
> to decide whether a value loaded in such mode can be punned to another
> mode
On 7/30/24 7:01 AM, Lulu Cheng wrote:
在 2024/7/26 下午8:43, Xi Ruoyao 写道:
We already had "si3_extend" insns and we hoped the fwprop or combine
passes can use them to remove unnecessary sign extensions. But this
does not always work: for cases like x << 1 | y, the compiler
tends to do
The following adds support for vector conditionals in C. The support
was nearly there already but c_objc_common_truthvalue_conversion
rejecting vector types. Instead of letting them pass there unchanged
I chose to instead skip it when parsing conditionals instead as a
variant with less possible
On Tue, 30 Jul 2024 at 08:31, Giuseppe D'Angelo
wrote:
>
> Hello!
>
> The attached patch implements adds support for P2591R5 in libstdc++
> (concatenation of strings and string_views, approved in Tokyo for C++26).
Thanks for this patch as well. This was on my TODO list so I'll be
happy to not
On Mon, 29 Jul 2024 at 21:58, Giuseppe D'Angelo wrote:
>
> Hi,
>
> And this is the corresponding change libstdc++.
Thanks for the patch. Do you have a copyright assignment for GCC in
place, or are you covered by a corporate assignment for KDAB?
If not, please complete that process, or contribute
On Tue, Jul 30, 2024 at 03:00:49PM +0200, Richard Biener wrote:
> As Jakub said the padding is already dealt with in the caller
> though I only added that there for convenience since padding is
> problematic in general.
>
> If you think XFmode is safe to transfer 10 bytes we could enable it,
> I
在 2024/7/26 下午8:43, Xi Ruoyao 写道:
We already had "si3_extend" insns and we hoped the fwprop or combine
passes can use them to remove unnecessary sign extensions. But this
does not always work: for cases like x << 1 | y, the compiler
tends to do
(sign_extend:DI
(ior:SI (ashift:SI
On Tue, 30 Jul 2024, Alexander Monakov wrote:
>
> On Tue, 30 Jul 2024, Richard Biener wrote:
>
> > > Oh, and please add a small comment why we don't use XFmode here.
> >
> > Will do.
> >
> > /* Do not enable XFmode, there is padding in it and it suffers
> >from
On Tue, 30 Jul 2024, Jakub Jelinek wrote:
> On Tue, Jul 30, 2024 at 03:43:25PM +0300, Alexander Monakov wrote:
> >
> > On Tue, 30 Jul 2024, Richard Biener wrote:
> >
> > > > Oh, and please add a small comment why we don't use XFmode here.
> > >
> > > Will do.
> > >
> > > /* Do not
On Tue, Jul 30, 2024 at 03:43:25PM +0300, Alexander Monakov wrote:
>
> On Tue, 30 Jul 2024, Richard Biener wrote:
>
> > > Oh, and please add a small comment why we don't use XFmode here.
> >
> > Will do.
> >
> > /* Do not enable XFmode, there is padding in it and it suffers
> >
On Tue, 30 Jul 2024, Richard Biener wrote:
> > Oh, and please add a small comment why we don't use XFmode here.
>
> Will do.
>
> /* Do not enable XFmode, there is padding in it and it suffers
>from normalization upon load like SFmode and DFmode when
>not using
On Tue, 30 Jul 2024, Jakub Jelinek wrote:
> On Tue, Jul 30, 2024 at 02:26:05PM +0200, Richard Biener wrote:
> > > > (Which implies that we should introduce TARGET_I387_MATH to parallel
> > > > TARGET_SSE_MATH some day...)
> > > >
> > > > > + default:
> > > > > + return false;
> > > >
>
Prathamesh Kulkarni wrote:
Thanks for your suggestions on RFC email, the attached patch adds support for
streaming of poly_int when it's degree <= accel's NUM_POLY_INT_COEFFS.
First, thanks a lot for your patch!
Secondly, it seems as if this patch is indented to fully or partially
fix the
On Tue, Jul 30, 2024 at 02:26:05PM +0200, Richard Biener wrote:
> > > (Which implies that we should introduce TARGET_I387_MATH to parallel
> > > TARGET_SSE_MATH some day...)
> > >
> > > > + default:
> > > > + return false;
> > >
> > > We don't want to enable HFmode for transfers?
>
>
On Tue, 30 Jul 2024, Filip Kastl wrote:
> > > > Ah, I see you fix those up. Then 2.) is left - the final block. Iff
> > > > the final block needs adjustment you know there was a path from
> > > > the default case to it which means one of its predecessors is dominated
> > > > by the default
On Tue, 30 Jul 2024, Uros Bizjak wrote:
> On Tue, Jul 30, 2024 at 1:07 PM Uros Bizjak wrote:
> >
> > On Tue, Jul 30, 2024 at 12:18 PM Richard Biener wrote:
> > >
> > > The following implements the hook, excluding x87 modes for scalar
> > > and complex float modes.
> > >
> > > Bootstrapped and
> Meanwhile I'll look into source code of the rest of the switch conversion
> pass.
> Switch conversion pass inserts conditions similar to what I'm doing so someone
> before me may have already solved how to properly fix dominators in this
> situation.
Oh nevermind. Switch conversion
> > > Ah, I see you fix those up. Then 2.) is left - the final block. Iff
> > > the final block needs adjustment you know there was a path from
> > > the default case to it which means one of its predecessors is dominated
> > > by the default case? In that case, adjust the dominator to cond_bb,
Jennifer Schmitz writes:
> As suggested in
> https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658249.html,
> this patch changes the instruction attribute of "*and_compare0" (TST)
> from
> alus_imm to logics_imm.
>
> The patch was bootstrapped and regtested on aarch64-linux-gnu, no regression.
Hi Jennifer,
> On 30 Jul 2024, at 09:47, Jennifer Schmitz wrote:
>
> Dear Richard,
> Thanks for the feedback. Great to see this patch approved! I made the changes
> as suggested.
> Best,
> Jennifer
> <0001-SVE-intrinsics-Add-strength-reduction-for-division-b.patch>
Thanks, I’m okay with the
> -Original Message-
> From: Jakub Jelinek
> Sent: Tuesday, July 30, 2024 3:16 PM
> To: Richard Biener
> Cc: Richard Sandiford ; Prathamesh Kulkarni
> ; gcc-patches@gcc.gnu.org
> Subject: Re: Support streaming of poly_int for offloading when it's
> degree <= accel's
On Tue, Jul 30, 2024 at 1:07 PM Uros Bizjak wrote:
>
> On Tue, Jul 30, 2024 at 12:18 PM Richard Biener wrote:
> >
> > The following implements the hook, excluding x87 modes for scalar
> > and complex float modes.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> >
> > OK?
> >
> >
Richard Biener writes:
> The following adds a target hook to specify whether regs of MODE can be
> used to transfer bits. The hook is supposed to be used for value-numbering
> to decide whether a value loaded in such mode can be punned to another
> mode instead of re-loading the value in the
Jakub Jelinek writes:
> On Tue, Jul 30, 2024 at 11:25:42AM +0200, Richard Biener wrote:
>> Only "relevant" stuff should be streamed - the offload code and all
>> trees refered to.
>
> Yeah.
>
>> > > I think all current issues are because of poly-* leaking in for cases
>> > > where a non-poly
On Tue, Jul 30, 2024 at 12:18 PM Richard Biener wrote:
>
> The following implements the hook, excluding x87 modes for scalar
> and complex float modes.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> OK?
>
> Thanks,
> Richard.
>
> * i386.cc (TARGET_MODE_CAN_TRANSFER_BITS):
This caused the tests to not be run. I may do further passes for non-run
next.
Tested on x86_64-pc-linux-gnu and checked test logs before/after.
PR c/53548
PR target/101529
PR tree-optimization/102359
* c-c++-common/fam-in-union-alone-in-struct-1.c: Fix whitespace
On Sat, Jul 27, 2024 at 4:29 AM Andrew Pinski wrote:
>
> While working on isel, I found that the current way of doing
> current_properties
> in function can easily make a mistake and having to do stuff like `(a & b )
> == 0`
> and `a |= b;` and `a &= ~b;` is not so obvious what was going on.
>
On Tue, Jul 30, 2024 at 12:22:01PM +0200, Richard Biener wrote:
> On Mon, Jul 29, 2024 at 5:15 PM Alejandro Colomar wrote:
> >
> > The old name was misleading.
> >
> > While at it, also rename some temporary variables that are used with
> > this function, for consistency.
> >
> > Link:
> >
On Mon, Jul 29, 2024 at 5:15 PM Alejandro Colomar wrote:
>
> The old name was misleading.
>
> While at it, also rename some temporary variables that are used with
> this function, for consistency.
>
> Link:
>
The following addresses another case where x87 FP loads mangle the
bit representation and thus are not suitable for a representative
in other types. VN was value-numbering a later integer load of 'x'
as the same as a former float load of 'x'.
We can use the new TARGET_MODE_CAN_TRANSFER_BITS hook
The following implements the hook, excluding x87 modes for scalar
and complex float modes.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK?
Thanks,
Richard.
* i386.cc (TARGET_MODE_CAN_TRANSFER_BITS): Define.
(ix86_mode_can_transfer_bits): New function.
---
The following adds a target hook to specify whether regs of MODE can be
used to transfer bits. The hook is supposed to be used for value-numbering
to decide whether a value loaded in such mode can be punned to another
mode instead of re-loading the value in the other mode and for SRA to
decide
On Tue, 30 Jul 2024, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Thursday, July 18, 2024 10:00 AM
> > To: Tamar Christina
> > Cc: GCC Patches ; Richard Sandiford
> >
> > Subject: RE: [RFC][middle-end] SLP Early break and control flow support in
> >
On Tue, Jul 30, 2024 at 11:25:42AM +0200, Richard Biener wrote:
> Only "relevant" stuff should be streamed - the offload code and all
> trees refered to.
Yeah.
> > > I think all current issues are because of poly-* leaking in for cases
> > > where a non-poly would have worked fine, but I have
On Tue, 30 Jul 2024, Richard Sandiford wrote:
> Richard Biener writes:
> > On Tue, 30 Jul 2024, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >> > On Tue, 30 Jul 2024, Prathamesh Kulkarni wrote:
> >> >
> >> >>
> >> >>
> >> >> > -Original Message-
> >> >> > From: Richard
Richard Biener writes:
> On Tue, 30 Jul 2024, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > On Tue, 30 Jul 2024, Prathamesh Kulkarni wrote:
>> >
>> >>
>> >>
>> >> > -Original Message-
>> >> > From: Richard Sandiford
>> >> > Sent: Monday, July 29, 2024 9:43 PM
>> >> > To:
On Sun, 24 Mar 2024 at 21:34, Björn Schäpers wrote:
>
> From: Björn Schäpers
>
> This fixes i.e. https://github.com/msys2/MSYS2-packages/issues/1937
> I don't know if I picked the right way to do it.
>
> When acceptable I think the declaration should be moved into
> ops-common.h, since then we
> -Original Message-
> From: Richard Biener
> Sent: Thursday, July 18, 2024 10:00 AM
> To: Tamar Christina
> Cc: GCC Patches ; Richard Sandiford
>
> Subject: RE: [RFC][middle-end] SLP Early break and control flow support in GCC
>
> On Wed, 17 Jul 2024, Tamar Christina wrote:
>
> > >
Hi,
v3 of patch 2/2 uses your suggested fix about using extra_cost as an
adjustment.
I did not introduce the ARM_INSN_COST macro you suggested because it seems
there's only a handful (maybe two) of cases where it could be used, and I
thought it wouldn't make the code really easier to
On Tue, 30 Jul 2024, Richard Sandiford wrote:
> Richard Biener writes:
> > On Tue, 30 Jul 2024, Prathamesh Kulkarni wrote:
> >
> >>
> >>
> >> > -Original Message-
> >> > From: Richard Sandiford
> >> > Sent: Monday, July 29, 2024 9:43 PM
> >> > To: Richard Biener
> >> > Cc: Prathamesh
On Tue, Jul 30, 2024 at 5:08 AM wrote:
>
> From: Pan Li
>
> For some target like target=amdgcn-amdhsa, we need to take care of
> vector bool types prior to general vector mode types. Or we may have
> the asm check failure as below.
>
> gcc.target/gcn/cond_smax_1.c scan-assembler-times
Richard Biener writes:
> On Tue, 30 Jul 2024, Prathamesh Kulkarni wrote:
>
>>
>>
>> > -Original Message-
>> > From: Richard Sandiford
>> > Sent: Monday, July 29, 2024 9:43 PM
>> > To: Richard Biener
>> > Cc: Prathamesh Kulkarni ; gcc-
>> > patc...@gcc.gnu.org
>> > Subject: Re: Support
On Mon, Jul 29, 2024 at 9:26 PM Tobias Burnus wrote:
>
> The problem is code like:
>
>MEM [(c_char * {ref-all})]
>
> where arr2 is the value expr '*arr2$13$linkptr'
> (i.e. indirect ref + decl name).
>
> Insidepass_omp_target_link::execute, there is a call to
> gimple_regimplify_operands but
Richard Biener writes:
> On Mon, 29 Jul 2024, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > On Mon, 29 Jul 2024, Jakub Jelinek wrote:
>> >> And, for the GET_MODE_INNER, I also meant it for Aarch64/RISC-V VL
>> >> vectors,
>> >> I think those should be considered as true by the hook,
Follow up fix:
As the !GCC$ attributes are now added in reverse order,
the 'stdcall' vs. 'fastcall' in the error message swapped order:
"Error: stdcall and fastcall attributes are not compatible" This didn't
show up here with -m64 ("Warning: 'stdcall' attribute ignored") and I
didn't run it
On Tue, 30 Jul 2024, 06:21 Ehrnsperger, Markus,
wrote:
> On 2024-07-29 12:16, Jonathan Wakely wrote:
>
> > On Mon, 29 Jul 2024 at 10:45, Jonathan Wakely
> wrote:
> >> On Mon, 29 Jul 2024 at 09:42, Ehrnsperger, Markus
> >> wrote:
> >>> Hi,
> >>>
> >>>
> >>> I'm attaching two files:
> >>>
> >>>
Dear Richard,
Thanks for the feedback. Great to see this patch approved! I made the changes
as suggested.
Best,
Jennifer
0001-SVE-intrinsics-Add-strength-reduction-for-division-b.patch
Description: Binary data
> On 29 Jul 2024, at 22:55, Richard Sandiford wrote:
>
> External email: Use
As suggested in
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658249.html,
this patch changes the instruction attribute of "*and_compare0" (TST) from
alus_imm to logics_imm.
The patch was bootstrapped and regtested on aarch64-linux-gnu, no regression.
OK for mainline?
Signed-off-by:
On Tue, 30 Jul 2024, Prathamesh Kulkarni wrote:
>
>
> > -Original Message-
> > From: Richard Sandiford
> > Sent: Monday, July 29, 2024 9:43 PM
> > To: Richard Biener
> > Cc: Prathamesh Kulkarni ; gcc-
> > patc...@gcc.gnu.org
> > Subject: Re: Support streaming of poly_int for
Hello!
The attached patch implements adds support for P2591R5 in libstdc++
(concatenation of strings and string_views, approved in Tokyo for C++26).
Thank you,
--
Giuseppe D'Angelo
From 0a4d44196bced41d97d8086343786b52a6f75faf Mon Sep 17 00:00:00 2001
From: Giuseppe D'Angelo
Date: Tue, 30
Applied the following patchlet to the documentation.
Johann
--
AVR: Propose to use attribute signal(n) via AVR-LibC's ISR_N.
gcc/
* doc/extend.texi (AVR Function Attributes): Propose to use
attribute signal(n) via AVR-LibC's ISR_N from avr/interrupt.h
diff --git
On Mon, 29 Jul 2024, Filip Kastl wrote:
> Hi Richard,
>
> > > Sorry, I'm not sure if I understand. Are you suggesting something like
> > > this?
> > >
> > > if (idom(default bb) == cond bb)
> > > {
> > > if (exists a path from default bb to final bb)
> > > {
> > > idom(final bb) =
> -Original Message-
> From: Jakub Jelinek
> Sent: Tuesday, July 30, 2024 2:57 PM
> To: Hongtao Liu
> Cc: Jiang, Haochen ; gcc-patches@gcc.gnu.org;
> Liu, Hongtao ; ubiz...@gmail.com
> Subject: Re: [PATCH v2] i386: Add non-optimize prefetchi intrins
>
> On Tue, Jul 30, 2024 at
On Mon, 29 Jul 2024, Richard Sandiford wrote:
> Richard Biener writes:
> > On Mon, 29 Jul 2024, Jakub Jelinek wrote:
> >> And, for the GET_MODE_INNER, I also meant it for Aarch64/RISC-V VL vectors,
> >> I think those should be considered as true by the hook, not false
> >> because maybe_ne.
> >
On Tue, Jul 30, 2024 at 09:28:46AM +0800, Hongtao Liu wrote:
> On Tue, Jul 30, 2024 at 9:27 AM Hongtao Liu wrote:
> >
> > On Fri, Jul 26, 2024 at 4:55 PM Haochen Jiang
> > wrote:
> > >
> > > Hi all,
> > >
> > > I added related O0 testcase in this patch.
> > >
> > > Ok for trunk and backport to
Committed, thanks Robin.
Pan
-Original Message-
From: Robin Dapp
Sent: Tuesday, July 30, 2024 2:28 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com; Robin
Dapp
Subject: Re: [PATCH v1] RISC-V: Take Xmode instead of Pmode
OK.
--
Regards
Robin
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, July 29, 2024 9:43 PM
> To: Richard Biener
> Cc: Prathamesh Kulkarni ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: Support streaming of poly_int for offloading when it's
> degree <= accel's NUM_POLY_INT_COEFFS
>
> External
On Tue, Jul 23, 2024 at 5:52 PM Takayuki 'January June' Suwa
wrote:
>
> According to the implemented pipeline model, this cost can be assumed to be
> 1 clock cycle.
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.cc (xtensa_insn_cost):
> Add a case statement for TYPE_FARITH.
On Tue, Jul 23, 2024 at 5:52 PM Takayuki 'January June' Suwa
wrote:
>
> We would like to implement the following to store a single-precision FP
> constant in a hardware FP register:
>
> - Load the bit-exact integer image of the pooled single-precision FP
>constant into an address (integer)
On Fri, Jul 19, 2024 at 1:35 PM Takayuki 'January June' Suwa
wrote:
>
> It is not wrong but also not optimal to specify that sibcalls require
> register A0 in RTX generation pass, by misleading DFA into thinking it
> is being used in function body.
> It would be better to specify it in
61 matches
Mail list logo
