Re: [PATCH] tree-ssa-math-opts: popcount (X) == 1 to (X ^ (X - 1)) > (X - 1) optimization [PR90693]

On Fri, 17 Nov 2023, Jakub Jelinek wrote: > Hi! > > Per the earlier discussions on this PR, the following patch folds > popcount (x) == 1 (and != 1) into (x ^ (x - 1)) > x - 1 (or <=) > if the corresponding popcount optab isn't implemented (I think any > double-word popcount or call will be

Re: [PATCH] c-family, middle-end: Add __builtin_c[lt]zg (arg, 0ULL) exception

On Mon, 20 Nov 2023, Richard Biener wrote: > On Sat, 18 Nov 2023, Jakub Jelinek wrote: > > > Hi! > > > > In https://sourceware.org/pipermail/libc-alpha/2023-November/152819.html > > Florian Weimer raised concern that the type-generic stdbit.h macros > > currently being considered suffer from

Re: [PATCH] c: Add __builtin_bit_complement

On Sat, Nov 18, 2023 at 8:38 PM Jakub Jelinek wrote: > > Hi! > > Another obstackle mentioned in the > https://sourceware.org/pipermail/libc-alpha/2023-November/152819.html > thread is that half of the stdc_{leading,trailing}_{zeros,ones}, > stdc_first_{leading,trailing}_{zero,one} and

Re: [PATCH] c-family, middle-end: Add __builtin_c[lt]zg (arg, 0ULL) exception

On Sat, 18 Nov 2023, Jakub Jelinek wrote: > Hi! > > In https://sourceware.org/pipermail/libc-alpha/2023-November/152819.html > Florian Weimer raised concern that the type-generic stdbit.h macros > currently being considered suffer from similar problem as old tgmath.h > implementation, in

Re: [PATCH] testsuite: scev: expect fail on ilp32

On Sun, 19 Nov 2023, Jeff Law wrote: > > > On 11/19/23 00:30, Alexandre Oliva wrote: > > > > I've recently patched scev-3.c and scev-5.c because it only passed by > > accident on ia32. It also fails on some (but not all) arm-eabi > > variants. It seems hard to characterize the conditions in

Re: [PATCH 0/4] Add vector pair support to PowerPC attribute((vector_size(32)))

On Mon, Nov 20, 2023 at 5:19 AM Michael Meissner wrote: > > This is simiilar to the patches on November 10th. > > * https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636077.html > * https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636078.html > *

Re: [PATCH 4/4] [ifcvt] if convert x=c ? y : y by RISC-V Zicond like insns

On 10/30/23 01:25, Fei Gao wrote: diff --git a/gcc/ifcvt.cc b/gcc/ifcvt.cc index 6e341fc4d4b..cfa9bc4b850 100644 --- a/gcc/ifcvt.cc +++ b/gcc/ifcvt.cc @@ -2911,7 +2911,7 @@ noce_try_sign_mask (struct noce_if_info *if_info) static bool noce_cond_zero_binary_op_supported (enum rtx_code op)

Re: [PATCH 3/4] [ifcvt] if convert x=c ? y op z : y by RISC-V Zicond like insns

On 10/30/23 01:25, Fei Gao wrote: +static bool +noce_cond_zero_binary_op_supported (enum rtx_code op) Function needs function comment. And again in your new tests, don't require explicit registers unless you know (due to use as function argument/return value) which register will be

Re: [PATCH 2/4] [ifcvt] if convert x=c ? y+z : y by RISC-V Zicond like insns

On 10/30/23 01:25, Fei Gao wrote: Conditional add, if zero rd = (rc == 0) ? (rs1 + rs2) : rs1 --> czero.nez rd, rs2, rc add rd, rs1, rd Conditional add, if non-zero rd = (rc != 0) ? (rs1 + rs2) : rs1 --> czero.eqz rd, rs2, rc add rd, rs1, rd Co-authored-by: Xiao Zeng gcc/ChangeLog:

Re: [PATCH 2/4] [ifcvt] if convert x=c ? y+z : y by RISC-V Zicond like insns

On 10/30/23 21:35, Fei Gao wrote: So just a few notes to further illustrate why I'm currently looking to take the VRULL+Ventana implementation.  The code above would be much better handled by just calling noce_emit_cmove.  noce_emit_cmove will go through the conditional move expander.  So

Re: [PATCH] [APX PPX] Support Intel APX PPX

On Fri, Nov 17, 2023 at 3:26 PM Hongyu Wang wrote: > > Intel APX PPX feature has been released in [1]. > > PPX stands for Push-Pop Acceleration. PUSH/PUSH2 and its corresponding POP > can be marked with a 1-bit hint to indicate that the POP reads the > value written by the PUSH from the stack.

Re: [PATCH] Initial support for AVX10.1

On Fri, Nov 10, 2023 at 9:42 AM Haochen Jiang wrote: > > gcc/ChangeLog: > > * common/config/i386/cpuinfo.h (get_available_features): > Add avx10_set and version and detect avx10.1. > (cpu_indicator_init): Handle avx10.1-512. > * common/config/i386/i386-common.cc >

Re: [BUG FIX] RISC-V: Fix VLS DI mode of slide1 instruction attribute

Oh. I suddenly realize this fix was included by Robin's indexed load/store fix patch. https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636654.html juzhe.zh...@rivai.ai From: Juzhe-Zhong Date: 2023-11-20 12:12 To: gcc-patches CC: kito.cheng; kito.cheng; jeffreyalaw; rdapp.gcc;

[PATCH 4/4] Add vector pair tests to PowerPC

The first patch in the vector pair series was previous posted. This patch needs that first patch. The first patch implemented the basic modes, and it allows for initialization of the modes. In addition, I added some optimizations for extracting and setting fields within the vector pair. The

[PATCH 3/4] Add integer vector pair mode support to PowerPC

The first two patches in the vector pair series were previous posted. This patch needs thos two patches. The first patch implemented the basic modes, and it allows for initialization of the modes. In addition, I added some optimizations for extracting and setting fields within the vector pair.

[PATCH 2/4] Vector pair floating point support for PowerPC

The first patch in the vector pair series was previous posted. This patch needs that first patch. The first patch implemented the basic modes, and it allows for initialization of the modes. In addition, I added some optimizations for extracting and setting fields within the vector pair. This

[PATCH 1/4] Add vector pair modes to PowerPC (patch attached)

(sorry I just posted the ChangeLog entry and not the patch). We have had several users ask us to implement ways of using the Power10 load vector pair and store vector pair instructions to give their code a speed up due to reduced memory bandwidth. I had originally posted the following patches:

[PATCH 1/4] Add basic vector pair mode support

Add basic support for vector_size(32). We have had several users ask us to implement ways of using the Power10 load vector pair and store vector pair instructions to give their code a speed up due to reduced memory bandwidth. I had originally posted the following patches: *

[PATCH 0/4] Add vector pair support to PowerPC attribute((vector_size(32)))

This is simiilar to the patches on November 10th. * https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636077.html * https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636078.html * https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636083.html *

[BUG FIX] RISC-V: Fix VLS DI mode of slide1 instruction attribute

The slide1 attributes are wrong for SEW=64 VLS modes. This patch fixes the following FAILs: FAIL: gcc.c-torture/execute/pr89369.c -O2 execution test FAIL: gcc.c-torture/execute/pr89369.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL:

Re: [RFA] New pass for sign/zero extension elimination

On 11/19/23 20:32, Xi Ruoyao wrote: On Sun, 2023-11-19 at 19:52 -0700, Jeff Law wrote: /* snip */ Unfortunately, I get some ICE building stage 1 libgcc with this patch on loongarch64-linux-gnu: during RTL pass: ext_dce ../../../gcc/libgcc/libgcc2.c: In function ‘__absvdi2’:

Re: [RFA] New pass for sign/zero extension elimination

On Sun, 2023-11-19 at 19:52 -0700, Jeff Law wrote: /* snip */ > > > Unfortunately, I get some ICE building stage 1 libgcc with this patch on > > loongarch64-linux-gnu: > > > > during RTL pass: ext_dce > > ../../../gcc/libgcc/libgcc2.c: In function ‘__absvdi2’: > >

Re: [PATCH] testsuite: arm: fix arm_movt cut

On 11/19/23 19:33, Alexandre Oliva wrote: I got spurious fails of tests that required arm_thumb1_movt_ok on a target cpu that did not support movt. Looking into it, I found the arm_movt property to have been cut into various procs that checked for different properties. They shouldn't share

Re: Re: RISC-V: Support XTheadVector extensions

As kito's suggestions. I just have a quick try. This patch should does following things: 1. Remove all new API that RVV1.0 doesn't have. E.g. vlb. They should be another separate patch to be reviewed. So the first series patch should be "Support part of theadvector API base on current

[PATCH] LoongArch: Add support for xorsign.

This patch adds support for xorsign pattern to scalar fp and vector. With the new expands, uniformly using vector bitwise logical operations to handle xorsign. On LoongArch64, floating-point registers and vector registers share the same register, so this patch also allows conversion between LSX

[PATCH] LoongArch: Add support for xorsign.

This patch adds support for xorsign pattern to scalar fp and vector. With the new expands, uniformly using vector bitwise logical operations to handle xorsign. On LoongArch64, floating-point registers and vector registers share the same register, so this patch also allows conversion between LSX

[PATCH] LoongArch: Add support for xorsign.

This patch adds support for xorsign pattern to scalar fp and vector. With the new expands, uniformly using vector bitwise logical operations to handle xorsign. On LoongArch64, floating-point registers and vector registers share the same register, so this patch also allows conversion between LSX

Re: [RFA] New pass for sign/zero extension elimination

On Sun, 2023-11-19 at 19:51 -0700, Jeff Law wrote: > > On 11/19/23 18:22, Oleg Endo wrote: > > > > On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote: > > > This is work originally started by Joern @ Embecosm. > > > > > > There's been a long standing sense that we're generating too many > > >

[PATCH] [x86] Support reduc_{and, ior, xor}_scal_m for V4HI/V8QI/V4QImode

Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ready push to trunk. gcc/ChangeLog: PR target/112325 * config/i386/i386-expand.cc (emit_reduc_half): Hanlde V8QImode. * config/i386/mmx.md (reduc__scal_): New expander. (reduc__scal_v4qi): Ditto.

[PATCH RFC] c++: mangle function template constraints

Tested x86_64-pc-linux-gnu. Are the library bits OK? Any comments before I push this? -- 8< -- Per https://github.com/itanium-cxx-abi/cxx-abi/issues/24 and https://github.com/itanium-cxx-abi/cxx-abi/pull/166 We need to mangle constraints to be able to distinguish between function templates

[pushed] c++: compare one level of template parms

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- There should never be a reason to compare more than one level of template parameters; additional levels are for the enclosing context, which is either irrelevant (for a template template parameter) or already compared (for a member

[pushed] c++: add DECL_IMPLICIT_TEMPLATE_PARM_P macro

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Let's use a more informative name instead of DECL_VIRTUAL_P directly. gcc/cp/ChangeLog: * cp-tree.h (DECL_TEMPLATE_PARM_CHECK): New. (DECL_IMPLICIT_TEMPLATE_PARM_P): New. (decl_template_parm_check): New. *

Re: [RFA] New pass for sign/zero extension elimination

On 11/19/23 19:23, Xi Ruoyao wrote: On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote: This is work originally started by Joern @ Embecosm. There's been a long standing sense that we're generating too many sign/zero extensions on the RISC-V port.  REE is useful, but it's really focused on a

Re: Re: [PATCH] RISC-V: Implement -mmemcpy-strategy= options[PR112537]

Committed, thanks jeff and juzhe. Thanks, Li Xu xu...@eswincomputing.com From: juzhe.zh...@rivai.ai Date: 2023-11-20 09:55 To: Li Xu; jeffreyalaw; gcc-patches CC: kito.cheng; palmer; Robin Dapp Subject: Re: Re: [PATCH] RISC-V: Implement -mmemcpy-strategy= options[PR112537] Jeff has approved

Re: [RFA] New pass for sign/zero extension elimination

On 11/19/23 18:22, Oleg Endo wrote: On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote: This is work originally started by Joern @ Embecosm. There's been a long standing sense that we're generating too many sign/zero extensions on the RISC-V port. REE is useful, but it's really focused on

[PATCH #4/4] testsuite: discard c++ exclusion on underaligned pointer warning

Having extended check_and_warn_address_or_pointer_of_packed_member to find the packed (short) enum pointer in the cast expression coming from the C++ front-end, and amended the C++ front end to mark short enums as TYPE_PACKED, C++ issues the same warning that C does for

Re: [PATCH #3/4] warn on cast of pointer to packed plus constant

c-c++-common/analyzer/null-deref-pr108251-smp-fetch_ssl_fc_has_early.c gets an unaligned pointer value warning on -fshort-enums targets in C, but not in C++. The former simplifies the offset-and-cast expression enough that check_and_warn_address_or_pointer_of_packed_member finds no more than a

[PATCH #2/4] c++: mark short-enums as packed

Unlike C, C++ doesn't mark enums shortened by -fshort-enums as packed. This makes for undesirable warning differences between C and C++, e.g. c-c++-common/analyzer/null-deref-pr108251-smp_fetch_ssl_fc_has_early*.c triggers a warning about a type cast from a pointer to enum that, when packed,

[PATCH] testsuite: arm: fix arm_movt cut

I got spurious fails of tests that required arm_thumb1_movt_ok on a target cpu that did not support movt. Looking into it, I found the arm_movt property to have been cut into various procs that checked for different properties. They shouldn't share the same test results cache entry, so I'm

Re:[pushed and backport] [PATCH] LoongArch: Modify MUSL_DYNAMIC_LINKER.

pushed to r14-5601 backport to r13-8085 and r12-9995. r12 and r13 simultaneously synchronized the patch that changed '/lib64' to '/lib'. 在 2023/11/18 上午11:15, Lulu Cheng 写道: Use no suffix at all in the musl dynamic linker name for hard float ABI. Use -sf and -sp suffixes in musl dynamic

Re: [RFA] New pass for sign/zero extension elimination

On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote: > This is work originally started by Joern @ Embecosm. > > There's been a long standing sense that we're generating too many > sign/zero extensions on the RISC-V port.  REE is useful, but it's really > focused on a relatively narrow part of the

Re: [committed] libstdc++: Fix aligned formatting of stacktrace_entry and thread::id [PR112564]

> From: Jonathan Wakely > Date: Thu, 16 Nov 2023 17:20:09 + > PR libstdc++/112564 > * include/std/stacktrace (formatter::format): Format according > to format-spec. > * include/std/thread (formatter::format): Use _Align_right as > default. > *

Re: [pushed][PATCH v2] LoongArch: Add code generation support for call36 function calls.

在 2023/11/20 上午9:51, Xi Ruoyao 写道: On Mon, 2023-11-20 at 09:09 +0800, chenglulu wrote: 在 2023/11/19 上午1:24, Xi Ruoyao 写道: On Sat, 2023-11-18 at 16:16 +0800, chenglulu wrote: Pushed to r14-5567. 在 2023/11/16 下午3:27, Lulu Cheng 写道: When compiling with '-mcmodel=medium', the function call is

Re: Re: [PATCH] RISC-V: Implement -mmemcpy-strategy= options[PR112537]

Jeff has approved your patch. You can commit it now. Btw, CC Robin to let him know this patch. Since he will support strcpy/strlenetc builtin with RVV instruction sequence. He will definitely needs compile option like this patch introduce. Thanks. juzhe.zh...@rivai.ai From: Li Xu Date:

Re: [pushed][PATCH v2] LoongArch: Add code generation support for call36 function calls.

On Mon, 2023-11-20 at 09:09 +0800, chenglulu wrote: > > 在 2023/11/19 上午1:24, Xi Ruoyao 写道: > > On Sat, 2023-11-18 at 16:16 +0800, chenglulu wrote: > > > Pushed to r14-5567. > > > > > > 在 2023/11/16 下午3:27, Lulu Cheng 写道: > > > > When compiling with '-mcmodel=medium', the function call is made

Re: [RFA] New pass for sign/zero extension elimination

On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote: > This is work originally started by Joern @ Embecosm. > > There's been a long standing sense that we're generating too many > sign/zero extensions on the RISC-V port. REE is useful, but it's really > focused on a relatively narrow part of

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

On Sun, Nov 19, 2023 at 5:15 PM Bruno Haible wrote: > David Edelsohn wrote: > > --disable-threads currently does not completely disable threads. Bruno > is > > suggesting --enable-threads=isoc that relies on mtx mutex functions in > libc. > > Unfortunately, as said in the other mail today,

Re: Re: [PATCH] RISC-V: Implement -mmemcpy-strategy= options[PR112537]

I've tested it and there are no issues with regression testing. Thanks, Li Xu xu...@eswincomputing.com From: Jeff Law Date: 2023-11-20 05:42 To: Li Xu; gcc-patches CC: kito.cheng; palmer; juzhe.zhong Subject: Re: [PATCH] RISC-V: Implement -mmemcpy-strategy= options[PR112537] On 11/16/23

Re: [pushed][PATCH v2] LoongArch: Add code generation support for call36 function calls.

在 2023/11/19 上午1:24, Xi Ruoyao 写道: On Sat, 2023-11-18 at 16:16 +0800, chenglulu wrote: Pushed to r14-5567. 在 2023/11/16 下午3:27, Lulu Cheng 写道: When compiling with '-mcmodel=medium', the function call is made through 'pcaddu18i+jirl' if binutils supports call36, otherwise the native

[PATCH v3 5/5] LoongArch: Use LSX for scalar FP rounding with explicit rounding mode

In LoongArch FP base ISA there is only the frint.{s/d} instruction which reads the global rounding mode. Utilize LSX for explicit rounding mode even if the operand is scalar. It seems wasting the CPU power, but still much faster than calling the library function. gcc/ChangeLog: *

[RFA] New pass for sign/zero extension elimination

This is work originally started by Joern @ Embecosm. There's been a long standing sense that we're generating too many sign/zero extensions on the RISC-V port. REE is useful, but it's really focused on a relatively narrow part of the extension problem. What Joern's patch does is introduce a

[PATCH v3 4/5] LoongArch: Remove lrint_allow_inexact

No functional change, just a cleanup. gcc/ChangeLog: * config/loongarch/loongarch.md (lrint_allow_inexact): Remove. (2): Check if == UNSPEC_FTINT instead of . --- gcc/config/loongarch/loongarch.md | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git

[PATCH v3 3/5] LoongArch: Use standard pattern name and RTX code for LSX/LASX rotate shift

Remove unnecessary UNSPECs and make the [x]vrotr[i] instructions useful with GNU vectors and auto vectorization. gcc/ChangeLog: * config/loongarch/lsx.md (bitimm): Move to ... (UNSPEC_LSX_VROTR): Remove. (lsx_vrotr_): Remove. (lsx_vrotri_): Remove. *

[PATCH v3 2/5] LoongArch: Use standard pattern name and RTX code for LSX/LASX muh instructions

Removes unnecessary UNSPECs and make the muh instructions useful with GNU vectors or auto vectorization. gcc/ChangeLog: * config/loongarch/simd.md (muh): New code attribute mapping any_extend to smul_highpart or umul_highpart. (mul3_highpart): New define_insn. *

[PATCH v3 1/5] LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578]

The usage LSX and LASX frint/ftint instructions had some problems: 1. These instructions raises FE_INEXACT, which is not allowed with -fno-fp-int-builtin-inexact for most C2x section F.10.6 functions (the only exceptions are rint, lrint, and llrint). 2. The "frint" instruction without

[PATCH v3 0/5] LoongArch: SIMD fixes and optimizations

The [1/5] patch is the PR112578 fix at https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637097.html. It has been changed to remove the nearbyint pattern (because nearbyint should not raise FE_INEXACT even if -ffp-int-builtin-inexact). As other patches depending on the simd.md file

Re: [PATCH] testsuite: Fix subexpressions with `scan-assembler-times'

On 11/19/23 04:27, Maciej W. Rozycki wrote: We have an issue with `scan-assembler-times' handling expressions using subexpressions as produced by capturing parentheses `()' in an odd way, and one that is inconsistent with `scan-assembler', `scan-assembler-not', etc. The problem comes from

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

On Sun, Nov 19, 2023 at 3:01 PM Bruno Haible wrote: > > I wrote: > > you (Arsen) should state in the documentation > > (gcc/doc/install.texi) that for --disable-threads to have this effect, > > one needs gettext version 0.22.4 or newer. > > Not in gcc/doc/install.texi, but elsewhere. This topic

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

I wrote: > you (Arsen) should state in the documentation > (gcc/doc/install.texi) that for --disable-threads to have this effect, > one needs gettext version 0.22.4 or newer. Not in gcc/doc/install.texi, but elsewhere. This topic is not relevant to the average user who installs GCC from a tarball

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

David Edelsohn wrote: > --disable-threads currently does not completely disable threads. Bruno is > suggesting --enable-threads=isoc that relies on mtx mutex functions in libc. Unfortunately, as said in the other mail today, relying only on mtx_* functions did not drop the dependency towards

libstdc++: Speed up push_back

Hi, this patch speeds up the push_back at -O3 significantly by making the reallocation to be inlined by default. _M_realloc_insert is general insertion that takes iterator pointing to location where the value should be inserted. As such it contains code to move other entries around that is quite

Re: [PATCH 5/5] Add an aligned_register_operand predicate

On 11/12/23 07:52, Richard Sandiford wrote: This patch adds a target-independent aligned_register_operand predicate, for use with register constraints that use filters to impose an alignment. The definition deliberately jetisons some of the historical baggage in general_operand. gcc/

Re: [PATCH 2/5] recog: Handle register filters

On 11/12/23 07:52, Richard Sandiford wrote: The main (but simplest) part of this patch makes constrain_operands take register filters into account. The rest of the patch adds register filter information to operand_alternative. Generally, if two register constraints have different register

Re: [PATCH 1/5] Add register filter operand to define_register_constraint

On 11/12/23 07:52, Richard Sandiford wrote: The main way of enforcing registers to be aligned is through HARD_REGNO_MODE_OK. But this is a global property that applies to all operands. A given (regno, mode) pair is either globally valid or globally invalid. This patch instead adds a way of

Re: [PATCH] c++: Set DECL_CONTEXT for __cxa_thread_atexit [PR99187]

On 11/16/23 16:39, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu. I don't have write access. -- >8 -- Modules streaming requires DECL_CONTEXT to be set on declarations that are streamed. This ensures that __cxa_thread_atexit is given translation unit context much

Re: [PATCH v2 2/5] c-family: Simplify attribute exclusion handling

On 11/16/23 19:53, Andrew Carlotti wrote: This patch changes the handling of mutual exclusions involving the target and target_clones attributes to use the generic attribute exclusion lists. Additionally, the duplicate handling for the always_inline and noinline attribute exclusion is

Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

On Sunday, November 19th, 2023 at 1:34 PM, Jason Merrill wrote: > > > On 11/19/23 13:36, waffl3x wrote: > > > I'm having trouble fixing the error for this case, the control flow > > when the functions are overloaded is much more complex. > > > > struct S { > > void f(this S&) {} > >

Re: [PATCH] RISC-V: Implement -mmemcpy-strategy= options[PR112537]

On 11/16/23 22:12, Li Xu wrote: From: xuli https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537 -mmemcpy-strategy=[auto|libcall|scalar|vector] auto: Current status, use scalar or vector instructions. libcall: Always use a library call. scalar: Only use scalar instructions. vector: Only use

[committed] RISC-V: Infrastructure for instruction fusion

I've been meaning to extract this and upstream it for a long time. The work is primarily Philipp from VRULL with one case added by Raphael and light bugfixing on my part. Essentially there's 10 distinct fusions supported and they can be selected individually by building a suitable mask

[PATCH, v2] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]

Hi Steve, On 11/19/23 01:04, Steve Kargl wrote: On Sat, Nov 18, 2023 at 11:12:55PM +0100, Harald Anlauf wrote: Regtested on x86_64-pc-linux-gnu. OK for mainline? Not in its current form. { + int first_int_kind = -1; + bool f2023 = ((gfc_option.allow_std & GFC_STD_F2023) != 0 +

Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

On 11/19/23 13:36, waffl3x wrote: I'm having trouble fixing the error for this case, the control flow when the functions are overloaded is much more complex. struct S { void f(this S&) {} void f(this S&, int) void g() { void (*fp)(S&) = } }; This seemed to have fixed the non

Re: [PATCH 40/44] RISC-V: Handle FP NE operator via inversion in cond-operation expansion

On 11/18/23 22:43, Maciej W. Rozycki wrote: We have no FNE.fmt machine instructions, but we can emulate them for the purpose of conditional-move and conditional-add operations by using the respective FEQ.fmt instruction and then swapping the data input operands or complementing the mask for

Re: building GNU gettext on AIX

I wrote in : > > The latest issue is that a few files in gettext ignore --disable-pthreads > > and creates a dependency on pthread_mutex. > ... > * If no, then the simple solution would be to pass the configure option >

Re: [PATCH 39/44] RISC-V/testsuite: Add branchless cases for generic FP cond adds

On 11/18/23 22:43, Maciej W. Rozycki wrote: Verify, for generic floating-point conditional-add operations that have a corresponding conditional-set machine instruction, that if-conversion triggers via `noce_try_addcc' at `-mbranch-cost=3' setting, which makes branchless code sequences emitted

Re: [PATCH 38/44] RISC-V/testsuite: Add branched cases for generic FP cond adds

On 11/18/23 22:43, Maciej W. Rozycki wrote: Verify, for generic floating-point conditional-add operations that have a corresponding conditional-set machine instruction, that if-conversion does *not* trigger at `-mbranch-cost=2' setting, which makes original branched code sequences cheaper

Re: [PATCH 37/44] RISC-V/testsuite: Add branchless cases for generic FP cond moves

On 11/18/23 22:43, Maciej W. Rozycki wrote: Verify, for generic floating-point conditional-move operations that have a corresponding conditional-set machine instruction, that if-conversion triggers (via `cond_move_convert_if_block', which doesn't report) at `-mbranch-cost=5' setting, which

Re: [PATCH 36/44] RISC-V/testsuite: Add branched cases for generic FP cond moves

On 11/18/23 22:42, Maciej W. Rozycki wrote: Verify, for generic floating-point conditional-move operations that have a corresponding conditional-set machine instruction, that if-conversion does *not* trigger at `-mbranch-cost=4' setting, which makes original branched code sequences cheaper

Re: [PATCH 35/44] RISC-V: Avoid extraneous integer comparison for FP comparisons

On 11/18/23 22:42, Maciej W. Rozycki wrote: We have floating-point coditional-set machine instructions for a subset of FP comparisons, so avoid going through a comparison against constant zero in `riscv_expand_float_scc' where not necessary, preventing an extraneous RTL instruction from being

Re: [PATCH 34/44] RISC-V: Provide FP conditional-branch instructions for if-conversion

On 11/18/23 22:42, Maciej W. Rozycki wrote: Do not expand floating-point conditional-branch RTL instructions right away that use a comparison operation that is either directly available as a machine conditional-set instruction or is NE, which can be emulated by EQ. This is so that

Re: [PATCH v2 1/3] LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578]

On Sun, 2023-11-19 at 22:30 +0800, Xi Ruoyao wrote: > +;; All these are controlled by -ffp-int-builtin-inexact. > +(define_int_attr simd_frint_pattern > +  [(UNSPEC_SIMD_FRINTRP "ceil") > +   (UNSPEC_SIMD_FRINTRZ "btrunc") > +   (UNSPEC_SIMD_FRINT

[committed] Fix missing mode on a few unspec/unspec_volatile operands

This is fix for a minor problem Jivan and I found while testing the ext-dce work originally from Joern. The ext-dce pass will transform zero/sign extensions into subreg accesses when the upper bits are actually unused. So it's more likely with the ext-dce work to get a sequence like this

Re: [PATCH 09/44] RISC-V: Rework branch costing model for if-conversion

On 11/18/23 22:36, Maciej W. Rozycki wrote: The generic branch costing model for if-conversion assumes a fixed cost of COSTS_N_INSNS (2) for a conditional branch, and that one half of that cost comes from a preceding condition-set instruction, such as with MODE_CC targets, and then the other

Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

On Sunday, November 19th, 2023 at 9:31 AM, Jason Merrill wrote: > > > On 11/19/23 08:39, waffl3x wrote: > > > Funny enough I ended up removing the ones I was thinking about, seems > > to always happen when I ask style questions but I'm glad to hear it's > > okay going forward. > > > > I'm

Re: [PATCH 22/44] RISC-V: Fold all the cond-move variants together

On 11/18/23 22:40, Maciej W. Rozycki wrote: Code in `riscv_expand_conditional_move' for Ventana and Zicond targets seems like bolted on as an afterthought rather than properly merged so as to handle all the cases together. You could characterize it that way. It was mostly a desire to not

Re: [PATCH 33/44] RISC-V: Also allow FP conditions in `riscv_expand_conditional_move'

On 11/18/23 22:42, Maciej W. Rozycki wrote: In `riscv_expand_conditional_move' we only let integer conditions through at the moment, even though code has already been prepared to handle floating-point conditions as well. Lift this restriction and only bail out if a non-word-mode integer

Re: [PATCH 32/44] RISC-V: Only use SUBREG if applicable in `riscv_expand_float_scc'

On 11/18/23 22:42, Maciej W. Rozycki wrote: A subsequent change to enable the processing of conditional moves on a floating-point condition by `riscv_expand_conditional_move' will cause `riscv_expand_float_scc' to be called for word-mode target RTX with RV64 targets. In that case an invalid

Re: [PATCH 31/44] RISC-V/testsuite: Add branchless cases for generic integer cond adds

On 11/18/23 22:41, Maciej W. Rozycki wrote: Verify, for generic integer conditional-add operations, if-conversion to trigger via `noce_try_addcc' at the respective sufficiently high `-mbranch-cost=' settings that make branchless code sequences produced by if-conversion cheaper than their

Re: [PATCH 30/44] RISC-V/testsuite: Add branched cases for generic integer cond adds

On 11/18/23 22:41, Maciej W. Rozycki wrote: Verify, for generic integer conditional-add operations, if-conversion *not* to trigger at the respective sufficiently low `-mbranch-cost=' settings that make original branched code sequences cheaper than their branchless equivalents if-conversion

Re: [PATCH 29/44] RISC-V: Add `addMODEcc' implementation for generic targets

On 11/18/23 22:41, Maciej W. Rozycki wrote: Provide RTL expansion of conditional-add operations for generic targets using a suitable sequence of base integer machine instructions according to cost evaluation by if-conversion. Use existing `-mmovcc' command line option to enable this

Re: [PATCH 28/44] RISC-V/testsuite: Add branchless cases for generic integer cond moves

On 11/18/23 22:41, Maciej W. Rozycki wrote: Verify, for generic integer conditional-move operations, if-conversion to trigger via `noce_try_cmove' at the respective sufficiently high `-mbranch-cost=' settings that make branchless code sequences produced by if-conversion cheaper than their

Re: [PATCH 27/44] RISC-V/testsuite: Add branched cases for generic integer cond moves

On 11/18/23 22:40, Maciej W. Rozycki wrote: Verify, for generic integer conditional-move operations, if-conversion *not* to trigger at the respective sufficiently low `-mbranch-cost=' settings that make original branched code sequences cheaper than their branchless equivalents if-conversion

Re: [PATCH 26/44] RISC-V: Add `movMODEcc' implementation for generic targets

On 11/18/23 22:40, Maciej W. Rozycki wrote: Provide RTL expansion of conditional-move operations for generic targets using a suitable sequence of base integer machine instructions according to cost evaluation by if-conversion. Add `-mmovcc' command line option to enable this transformation,

Re: [PATCH 25/44] RISC-V: Implement `riscv_emit_unary' helper

On 11/18/23 22:40, Maciej W. Rozycki wrote: Add a `riscv_emit_unary' helper for unary operations, complementing `riscv_emit_binary'. gcc/ * config/riscv/riscv-protos.h (riscv_emit_unary): New prototype. * config/riscv/riscv.cc (riscv_emit_unary): New function. OK

Re: [PATCH 24/44] RISC-V/testsuite: Add branchless cases for T-Head non-equality cond moves

On 11/18/23 22:40, Maciej W. Rozycki wrote: Verify, for T-Head targets and the non-equality integer conditional-move operations, that if-conversion triggers via `noce_try_cmove' at `-mbranch-cost=2' setting, which makes branchless code sequences produced by if-conversion cheaper than their

Re: [PATCH 23/44] RISC-V/testsuite: Add branched cases for T-Head non-equality cond moves

On 11/18/23 22:40, Maciej W. Rozycki wrote: Verify, for T-Head targets and the non-equality integer conditional-move operations, that if-conversion does *not* trigger at `-mbranch-cost=1' setting, which makes original branched code sequences cheaper than their branchless equivalents

Re: [PATCH 21/44] RISC-V: Also accept constants for T-Head cond-move data input operands

On 11/18/23 22:39, Maciej W. Rozycki wrote: There is no need for the requirement for conditional-move data input operands to be stricter for T-Head targets than for short forward branch targets and limit them to registers only. They are keyed according to the `sfb_alu_operand' predicate,

Re: [PATCH 20/44] RISC-V: Also accept constants for T-Head cond-move comparison operands

On 11/18/23 22:39, Maciej W. Rozycki wrote: There is no need for the requirement for conditional-move comparison operands to be stricter for T-Head targets than for other targets and limit them to registers only. Constants will be reloaded if required just as with branches or other-target

Re: [PATCH 19/44] RISC-V/testsuite: Add branchless cases for equality cond-move operations

On 11/18/23 22:39, Maciej W. Rozycki wrote: Verify, for Ventana and Zicond targets and the equality conditional-move operations, that if-conversion triggers via `noce_try_cmove' at the respective sufficiently high `-mbranch-cost=' settings that make branchless code sequences produced by

Re: [PATCH 18/44] RISC-V/testsuite: Add branched cases for equality cond-move operations

On 11/18/23 22:38, Maciej W. Rozycki wrote: Verify, for Ventana and Zicond targets and the equality conditional-move operations, that if-conversion does *not* trigger at the respective sufficiently low `-mbranch-cost=' settings that make original branched code sequences cheaper than their

Re: [PATCH 17/44] RISC-V: Avoid extraneous EQ or NE operation in cond-move expansion

On 11/18/23 22:38, Maciej W. Rozycki wrote: In the non-zero case there is no need for the conditional value used by Ventana and Zicond integer conditional operations to be specifically 1. Regardless we canonicalize it by producing an extraneous conditional-set operation, such as with the

  1   2   >