Re: Re: [PATCH V2] RISC-V: Support POPCOUNT auto-vectorization

>> From my recollection this is usually 30-40% faster than the naive tree >> adder and also amenable to vectorization. As long as the multiplication >> is not terribly slow, that is. Mula's algorithm should be significantly >> faster even, another 30% IIRC. >> I'm not against continuing with th

Re: [PATCH v3 1/4] diagnostics: libcpp: Add LC_GEN linemaps to support in-memory buffers

On Fri, Jul 28, 2023 at 6:58 PM David Malcolm wrote: > > On Fri, 2023-07-21 at 19:08 -0400, Lewis Hyatt wrote: > > Add a new linemap reason LC_GEN which enables encoding the location > > of data > > that was generated during compilation and does not appear in any > > source file. > > There could b

Re: [PATCH] analyzer: Add support of placement new and improved operator new [PR105948]

On Mon, 2023-07-31 at 13:46 +0200, Benjamin Priour wrote: > Hi Dave, > > On Fri, Jul 21, 2023 at 10:10 PM David Malcolm > wrote: [...snip...] > > > > I see that we have test coverage for: > >   noexcept-new.C: -fno-exceptions with new vs nothrow-new > > whereas: > >   new-2.C has (implicitly)

Re: [PATCH v2] combine: Narrow comparison of memory and constant

On 7/31/23 15:43, Prathamesh Kulkarni via Gcc-patches wrote: On Mon, 19 Jun 2023 at 19:59, Stefan Schulze Frielinghaus via Gcc-patches wrote: Comparisons between memory and constants might be done in a smaller mode resulting in smaller constants which might finally end up as immediates inst

libbacktrace patch committed

This libbacktrace patch, based on one by Andres Freund, uses the _pgmptr variable declared on Windows to find the executable file name if none is specified. Bootstrapped and ran libbacktrace testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian Patch from Andres Freund: * configure.ac: C

[COMMITTEDv2] Fix PR 93044: extra cast is not removed

In this case we are not removing convert to a bigger size back to the same size (or smaller) if signedness does not match. For an example: ``` signed char _1; ... _1 = *a_4(D); b_5 = (short unsigned int) _1; _2 = (unsigned char) b_5; ``` The inner cast is not needed and can be removed but w

[PATCH] tree-pretty-print: handle COMPONENT_REF with non-decl RHS

Tested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- In the C++ front end, a COMPONENT_REF's second operand isn't always a decl (at least at template parse time). This patch makes the generic pretty printer not ICE when printing such a COMPONENT_REF. gcc/ChangeLog: * tr

[PATCH] c++: improve debug_tree for templated types/decls

Tested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- gcc/cp/ChangeLog: * ptree.cc (cxx_print_decl): Check for DECL_LANG_SPECIFIC and TS_DECL_COMMON only when necessary. Print DECL_TEMPLATE_INFO for all decls that have it, not just VAR_DECL or FUNCTION_DEC

[PATCH] preprocessor: c++: Support `#pragma GCC target' macros [PR87299]

`#pragma GCC target' is not currently handled in preprocess-only mode (e.g., when running gcc -E or gcc -save-temps). As noted in the PR, this means that if the target pragma defines any macros, those macros are not effective in preprocess-only mode. Similarly, such macros are not effective when co

Re: [r14-2834 Regression] FAIL: gcc.target/i386/pr87007-5.c scan-assembler-times vxorps[^\n\r]*xmm[0-9] 1 on Linux/x86_64

On Sat, Jul 29, 2023 at 11:55 AM haochen.jiang via Gcc-regression wrote: > > On Linux/x86_64, > > b9d7140c80bd3c7355b8291bb46f0895dcd8c3cb is the first bad commit > commit b9d7140c80bd3c7355b8291bb46f0895dcd8c3cb > Author: Jan Hubicka > Date: Fri Jul 28 09:16:09 2023 +0200 > > loop-split im

Re: [RFC v2] RISC-V: Add Ztso atomic mappings

On 7/17/23 15:28, Patrick O'Neill wrote: The RISC-V Ztso extension currently has no effect on generated code. With the additional ordering constraints guarenteed by Ztso, we can emit more optimized atomic mappings than the RVWMO mappings. This PR defines a strengthened version of Andrea Parri

[PING][PATCH] ira: update allocated_hardreg_p[] in improve_allocation() [PR110254]

Ping On 21/07/23 3:43 pm, Surya Kumari Jangala via Gcc-patches wrote: > The improve_allocation() routine does not update the > allocated_hardreg_p[] array after an allocno is assigned a register. > > If the register chosen in improve_allocation() is one that already has > been assigned to a confl

[PATCH] Adjust testcase for more optimal codegen.

After b9d7140c80bd3c7355b8291bb46f0895dcd8c3cb is the first bad commit commit b9d7140c80bd3c7355b8291bb46f0895dcd8c3cb Author: Jan Hubicka Date: Fri Jul 28 09:16:09 2023 +0200 loop-split improvements, part 1 Now we have vpbroadcastd %ecx, %xmm0 vpaddd .LC3(%rip), %xmm0, %xmm0 v

[PATCH] x86: fold two of vec_dupv2df's alternatives

By using Yvm in the source, both can be expressed in one. gcc/ * sse.md (vec_dupv2df): Fold the middle two of the alternatives. --- a/gcc/config/i386/sse.md +++ b/gcc/config/i386/sse.md @@ -13784,21 +13784,20 @@ (set_attr "mode" "DF,DF,V1DF,V1DF,V1DF,V2DF,V1DF,V1DF,V1DF")])

[PATCH RESEND] libatomic: drop redundant all-multi command

./multilib.am already specifies this same command, and make warns about the earlier one being ignored when seeing the later one. All that needs retaining to still satisfy the preceding comment is the extra dependency. libatomic/ * Makefile.am (all-multi): Drop commands. * Makefile

RE: [PATCH] x86: fold two of vec_dupv2df's alternatives

> -Original Message- > From: Jan Beulich > Sent: Tuesday, August 1, 2023 1:49 PM > To: gcc-patches@gcc.gnu.org > Cc: Liu, Hongtao ; Kirill Yukhin > > Subject: [PATCH] x86: fold two of vec_dupv2df's alternatives > > By using Yvm in the source, both can be expressed in one. > > gcc/ >

Re: [PATCH V2] [PATCH 3/5] [RISC-V] Generate Zicond instruction for select pattern with condition eq or neq to 0

On 7/29/23 03:13, Xiao Zeng wrote: This patch recognizes Zicond patterns when the select pattern with condition eq or neq to 0 (using eq as an example), namely: 1 rd = (rs2 == 0) ? non-imm : 0 2 rd = (rs2 == 0) ? non-imm : non-imm 3 rd = (rs2 == 0) ? reg : non-imm 4 rd = (rs2 == 0) ? reg : re

[PATCH V3] VECT: Support CALL vectorization for COND_LEN_*

From: Ju-Zhe Zhong Hi, Richard and Richi. Base on the suggestions from Richard: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625396.html This patch choose (1) approach that Richard provided, meaning: RVV implements cond_* optabs as expanders. RVV therefore supports both IFN_COND_ADD an

Re: [PATCH V2] RISC-V: Support POPCOUNT auto-vectorization

>>> I'm not against continuing with the more well-known approach for now >>> but we should keep in mind that might still be potential for improvement. > > No. I don't think it's faster. I did a quick check on my x86 laptop and it's roughly 25% faster there. That's consistent with the literature.

[PATCH v1] RISC-V: Support RVV VFSUB and VFRSUB rounding mode intrinsic API

From: Pan Li This patch would like to support the rounding mode API for both the VFSUB and VFRSUB as below samples. * __riscv_vfsub_vv_f32m1_rm * __riscv_vfsub_vv_f32m1_rm_m * __riscv_vfsub_vf_f32m1_rm * __riscv_vfsub_vf_f32m1_rm_m * __riscv_vfrsub_vf_f32m1_rm * __riscv_vfrsub_vf_f32m1_rm_m Sig

Re: [RFC] light expander sra for parameters and returns

Hi, Richard Biener writes: > On Mon, 24 Jul 2023, Jiufu Guo wrote: > >> >> Hi Martin, >> >> Not sure about your current option about re-using the ipa-sra code >> in the light-expander-sra. And if anything I could input please >> let me know. >> >> And I'm thinking about the difference betwe

<    1   2