[PATCH 1/7] Support Intel SM4 EVEX instructions

gcc/ChangeLog: * config/i386/i386-builtin-types.def: Add DEF_FUNCTION_TYPE (V16SI, V16SI, V16SI). * config/i386/i386-builtin.def (BDESC): Add new builtins. * config/i386/i386-expand.cc (ix86_expand_args_builtin): Handle V16SI_FTYPE_V16SI_V16SI. * con

[PATCH 6/7] Support Intel MOVRS

From: "Hu, Lin1" gcc/ChangeLog: * common/config/i386/cpuinfo.h (get_available_features): Detect movrs. * common/config/i386/i386-common.cc (OPTION_MASK_ISA2_MOVRS_SET): New. (OPTION_MASK_ISA2_MOVRS_UNSET): Ditto. (ix86_handle_option): Handle -mmovrs.

[PATCH 5/7] Support Intel AMX-FP8

From: Liwei Xu gcc/ChangeLog: * common/config/i386/cpuinfo.h (get_available_features): Detect amx-fp8. * common/config/i386/i386-common.cc (OPTION_MASK_ISA2_AMX_FP8_SET): New macros. (OPTION_MASK_ISA2_AMX_FP8_UNSET): Ditto. (ix86_handle_option): Ha

[PATCH 7/7] Support Intel AMX-MOVRS

From: "Hu, Lin1" gcc/ChangeLog: * common/config/i386/cpuinfo.h (get_available_features): Detect AMX-MOVRS. * common/config/i386/i386-common.cc (OPTION_MASK_ISA2_AMX_MOVRS_SET): New. (OPTION_MASK_ISA2_AMX_MOVRS_UNSET): Ditto. (ix86_handle_option): H

Re: [PATCH][Backport][GCC13] RISC-V: Fix missing boolean_expression in zmmul extension

LGTM :) On Mon, Oct 21, 2024 at 6:54 PM Liao Shihua wrote: > > This patch has been merged in GCC-14 but it needs to be added into GCC-13 as > well. > > Missing boolean_expression TARGET_ZMMUL in riscv_rtx_costs() cause different > instructions when > multiplying an integer with a constant. ( >

[PATCH 4/7] Support Intel AMX-TRANSPOSE

gcc/ChangeLog: * common/config/i386/cpuinfo.h (get_available_features): Detect AMX-TRANSPOSE. * common/config/i386/i386-common.cc (OPTION_MASK_ISA2_AMX_TRANSPOSE_SET, OPTION_MASK_ISA2_AMX_TRANSPOSE_UNSET): New. (ix86_handle_option): Handle -mamx-tran

[PATCH 3/7] Support Intel AMX-TF32

gcc/ChangeLog: * common/config/i386/cpuinfo.h (get_available_features): Detect AMX-TF32. * common/config/i386/i386-common.cc (OPTION_MASK_ISA2_AMX_TF32_SET, OPTION_MASK_ISA2_AMX_TF32_UNSET): New. (ix86_handle_option): Handle -mamx-tf32. * common/conf

[PATCH 2/7] Support Intel AMX-AVX512

gcc/ChangeLog: * common/config/i386/cpuinfo.h (get_available_features): Detect AMX-AVX512. * common/config/i386/i386-common.c (OPTION_MASK_ISA2_AMX_AVX512_SET, OPTION_MASK_ISA2_AMX_AVX512_UNSET): New. (ix86_handle_option): Handle -mamx-avx512. * comm

[PATCH 0/7] Support Intel Diamond Rapid new features

Hi all, ISE054 has just been released and you can find doc from here: https://cdrdv2.intel.com/v1/dl/getContent/671368 Diamond Rapids features are added in this ISE, including AMX related instructions, SM4 EVEX extension and MOVRS/PREFETCHRST2. The following seven patches will add all the new f

[PATCH] RISC-V: Fix rvv builtin function groups registration asynchronously.

In the origin, cc1 registers rvv builtins with turn on all sub vector extensions but lto not. It makes lto use the asynchronous DECL_MD_FUNCTION_CODE from lto-objects. Example: riscv64-unknown-elf-gcc -flto gcc/testsuite/gcc.target/riscv/rvv/base/bug-3.c -O2 -march=rv64gcv bug-3.c: In function '

[PATCH] RISC-V: Remove skip of decl in registered_function.

The GTY skip makes GGC clean the registered functions wrongly in lto. Example: riscv64-unknown-elf-gcc -flto gcc/testsuite/gcc.target/riscv/rvv/base/bug-3.c -O2 -march=rv64gcv In file included from bug-3.c:2: internal compiler error: Segmentation fault gcc/ChangeLog: *riscv-vector-built

Re: SVE intrinsics: Fold constant operands for svlsl.

Hi, > On 17 Oct 2024, at 12:38 PM, Kyrylo Tkachov wrote: > > Hi Soumya > >> On 17 Oct 2024, at 06:10, Soumya AR wrote: >> >> Hi Richard, >> >> Thanks for the feedback. I’ve updated the patch with the suggested change. >> Ok for mainline? >> >> Best, >> Soumya >> >>> On 14 Oct 2024, at 6:40 PM, R

Re: [PATCH 4/4] c++: enable modules by default in c++20

On 10/15/24 10:57 AM, Jakub Jelinek wrote: On Fri, Oct 11, 2024 at 10:41:36PM -0400, Jason Merrill wrote: The intent is that C++20 module header units obsolete PCH; they serve the same function and are more flexible (you can import multiple header units). Though, simple use of -std=c++20 or -s

[PATCH] i386: Optimize EQ/NE comparison between avx512 kmask and -1.

r15-974-gbf7745f887c765e06f2e75508f263debb60aeb2e has optimized for jcc/setcc, but missed movcc. The patch supports movcc. Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ready push to trunk. gcc/ChangeLog: PR target/117232 * config/i386/sse.md (*kortest_cmp_movqicc):

[PATCH] [GCC13/GCC12] Fix testcase.

The optimization relies on other patterns which are only available at GCC14 and obove, so restore the xfail for GCC13/12 branch. Pushed as an obvious fix. gcc/testsuite/ChangeLog: * gcc.target/i386/avx512bw-pr103750-2.c: Add xfail for ia32. --- gcc/testsuite/gcc.target/i386/avx512bw-pr1

Re: [PATCH] testsuite: Fix typo in ext-floating19.C

On 10/20/24 7:48 AM, Stefan Schulze Frielinghaus wrote: gcc/testsuite/ChangeLog: * g++.dg/cpp23/ext-floating19.C: Fix typo for bfloat16 guard. --- Ok for mainline? OK, thanks (and qualifies as obvious). gcc/testsuite/g++.dg/cpp23/ext-floating19.C | 2 +- 1 file changed, 1 insert

Re: [PATCH] c++/modules: Handle forward-declared class types

On 10/21/24 8:12 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK. > -- >8 -- In some cases we can access members of a namespace-scope class without ever having performed name-lookup on it; this can occur when a forward-declaration of the class i

[PATCH][Backport][GCC13] RISC-V: Fix missing boolean_expression in zmmul extension

This patch has been merged in GCC-14 but it needs to be added into GCC-13 as well. Missing boolean_expression TARGET_ZMMUL in riscv_rtx_costs() cause different instructions when multiplying an integer with a constant. ( https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1482 ) int foo

Re: [PATCH] c++: redundant hashing in register_specialization

On 10/17/24 6:04 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK, thanks. -- >8 -- After r15-4050-g5dad738c1dd164 register_specialization needs to set elt.hash to the (maybe) precomputed hash in order to avoid redundantly rehashing.

Re: [PATCH 3/3] gcc: Add --enable-multilib-space option

> Option names should be inside @option{}, e.g. @option{-O2}. Thanks. Will be updated in the next version. I'll wait for some review of the functional bits of this series. -- -keith signature.asc Description: PGP signature

Re: counted_by attribute and type compatibility

Am Montag, dem 21.10.2024 um 21:09 + schrieb Joseph Myers: > On Sat, 19 Oct 2024, Martin Uecker wrote: > > > Hi Quin and Joseph, > > > > I saw that there is now new code in tu_tagged_types_compatible > > which makes structure type incompatible depending on whether > > there is ac counted_by a

Re: [PATCH 3/3] gcc: Add --enable-multilib-space option

On Sat, 19 Oct 2024, Keith Packard wrote: > +@item --enable-multilib-space > +Double the set of target libraries built by building two versions of > +each specified by the options above, one using -O2 and another using > +-Os. During linking, the -O2 variant will be selected by > +default. Select

Re: counted_by attribute and type compatibility

On Sat, 19 Oct 2024, Martin Uecker wrote: > Hi Quin and Joseph, > > I saw that there is now new code in tu_tagged_types_compatible > which makes structure type incompatible depending on whether > there is ac counted_by attribute. Is this what we want? I think a > warning might make more sense a

[PATCH v3 0/3] Automate creation of -O2 and -Os multilib variants

This is the third version of this patch series. Changes from v2: * Change the default value of the new --enable-multilib-space option to disabled. I didn't catch this regression because I was only testing with the new option enabled. The Linaro regression tests identified the issue. --

[PATCH v3 3/3] gcc: Add --enable-multilib-space option

This option adds a per-multilib variant that specifies -Os instead of the default. Signed-off-by: Keith Packard --- config-ml.in | 2 +- gcc/Makefile.in | 32 +++- gcc/configure| 13 + gcc/configure.ac | 7 +++ gcc/doc/instal

[PATCH v3 1/3] libgcc: Use -Os/-Oz from CC or CFLAGS

Override other optimization settings with any -Os or -Oz found in CC or CFLAGS. Signed-off-by: Keith Packard --- libgcc/Makefile.in | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in index ffc45f21267..25710636938 100644 --- a/l

[PATCH v3 2/3] arm: Add missing multilib default values

The arm multilib configuration includes two more parameters which affect multilib selection, marm/mthumb and mfloat-abi. Without those, the default multilib selection is mis-specified and the only reason it works is because '.' is the fall-back path. Add "marm" and "mfloat-abi=soft" to MULTILIB_DE

Re: counted_by attribute and type compatibility

Hi, Martin, > On Oct 19, 2024, at 05:50, Martin Uecker wrote: > > > Hi Quin and Joseph, > > I saw that there is now new code in tu_tagged_types_compatible > which makes structure type incompatible depending on whether > there is ac counted_by attribute. Is this what we want? Yes, I just chec

[Patch] GCN: Initial generic-target handling (was: [PATCH] amdgcn: Refactor device settings into a def file)

I have now attached a proper version of my patch, which is relative to your patch. OK once your patch is in? * * * This adds -march=gfx10-3-generic and -march=gfx11-generic support to the compiler, permitting in principle to compile one binary for all gfx103x and gfx11xx GPUs, respectively.

[committed][PR rtl-optimization/116488] Fix SIGN_EXTEND source handling in ext-dce

A while back I noticed that the code to call carry_backpropagate was being called after the optimization step. Which seemed wrong, but at the time I didn't have a testcase showing it as a problem. Now I have 4 :-) The way things used to work, the extension would be stripped away before call

[PATCH v2 06/11] RISC-V: Implement TARGET_OPTION_VALID_VERSION_ATTRIBUTE_P

This patch implements the TARGET_OPTION_VALID_VERSION_ATTRIBUTE_P for RISC-V. This hook is used to process attribute ((target_version ("..."))). Co-Developed-by: Hank Chang gcc/ChangeLog: * config/riscv/riscv-protos.h (riscv_option_valid_version_attribute_p): Declare. (r

Re: [PATCH] RISC-V: Add function multiversioning support

> On Oct 21, 2024, at 10:41, Kito Cheng wrote: > > Could you add testcases? Also, could you splitted that into smaller > patches to make it easier to review? > Done! Link: https://patchwork.sourceware.org/project/gcc/list/?series=39772

[PATCH v2 11/11] RISC-V: Add Multi-Versioning Test Cases

This patch adds test cases for the Function Multi-Versioning (FMV) feature for RISC-V, which reuses the existing test cases from the aarch64 and ported them to RISC-V. gcc/testsuite/ChangeLog: * g++.target/riscv/mv-symbols1.C: New test. * g++.target/riscv/mv-symbols2.C: New test.

[PATCH v2 10/11] RISC-V: Implement TARGET_GENERATE_VERSION_DISPATCHER_BODY and TARGET_GET_FUNCTION_VERSIONS_DISPATCHER

This patch implements the TARGET_GENERATE_VERSION_DISPATCHER_BODY and TARGET_GET_FUNCTION_VERSIONS_DISPATCHER for RISC-V. This is used to generate the dispatcher function and get the dispatcher function for function multiversioning. This patch copies many codes from commit 0cfde688e213 ("[aarch64]

[PATCH v2 09/11] RISC-V: Reapply target_version attribute after target attribute

To ensure that the target_version attribute is applied after target attributes. gcc/ChangeLog: * config/riscv/riscv-target-attr.cc (riscv_option_valid_attribute_p): Reapply target_version attribute after target attribute --- gcc/config/riscv/riscv-target-attr.cc | 13

[PATCH v2 08/11] RISC-V: Do not inline when callee is versioned but caller is not

When the callee is versioned but the caller is not, we should not inline the callee into the caller, to prevent the default version of the callee from being inlined into a not versioned caller. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_can_inline_p): Refuse to inline when call

[PATCH v2 07/11] RISC-V: Implement TARGET_MANGLE_DECL_ASSEMBLER_NAME

This patch implements the TARGET_MANGLE_DECL_ASSEMBLER_NAME for RISC-V. This is used to add function multiversioning suffixes to the assembler name. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_mangle_decl_assembler_name): New function. (TARGET_MANGLE_DECL_ASSEMBLER_NAME)

[PATCH v2 03/11] RISC-V: Implement Priority syntax parser for Function Multi-Versioning

This patch adds the priority syntax parser to support the Function Multi-Versioning (FMV) feature in RISC-V. This feature allows users to specify the priority of the function version in the attribute syntax. Chnages based on RISC-V C-API PR: https://github.com/riscv-non-isa/riscv-c-api-doc/pull/85

[PATCH v2 05/11] RISC-V: Implement TARGET_COMPARE_VERSION_PRIORITY and TARGET_OPTION_FUNCTION_VERSIONS

This patch implements TARGET_COMPARE_VERSION_PRIORITY and TARGET_OPTION_FUNCTION_VERSIONS for RISC-V. The TARGET_COMPARE_VERSION_PRIORITY is implemented to compare the priority of two function versions based on the rules defined in the RISC-V C-API Doc PR #85: https://github.com/riscv-non-isa/ris

[PATCH v2 04/11] RISC-V: Implement riscv_minimal_hwprobe_feature_bits

This patch implements the riscv_minimal_hwprobe_feature_bits feature for the RISC-V target. The feature bits are defined in the previous patch [1] to provide bitmasks of ISA extensions that defined in RISC-V C-API. Thus, we need a function to generate the feature bits for IFUNC resolver to dispatch

[PATCH v2 02/11] RISC-V: Split riscv_process_target_attr with const char *args argument

This patch splits static bool riscv_process_target_attr (tree args, location_t loc) into two functions: - bool riscv_process_target_attr (const char *args, location_t loc) - static bool riscv_process_target_attr (tree args, location_t loc) Thus, we can call `riscv_process_target_attr` with a `con

[PATCH v2 01/11] Introduce TARGET_CLONES_ATTR_SEPARATOR for RISC-V

Some architectures may use ',' in the attribute string, but it is not used as the separator for different targets. To avoid conflict, we introduce a new macro TARGET_CLONES_ATTR_SEPARATOR to separate different clones. As an example, according to RISC-V C-API Specification [1], RISC-V allows ',' in

[PATCH v2 00/11] RISC-V: Add Function Multi-Versioning support

This patch series adds support for Function Multi-Versioning (FMV) to RISC-V. The FMV feature allows users to specify multiple versions of a function and select the version at runtime based on the target_clones and target_version attributes, which follow the RISC-V C-API Docs [1] and the existing p

Re: [PATCH] aarch64: libstdc++: Use shufflevector instead of shuffle in opt_random.h

On Mon, 21 Oct 2024 at 17:29, Ricardo Jesus wrote: > > On 10/14/24 14:37, Jonathan Wakely wrote: > > > > > > On Mon, 14 Oct 2024 at 14:36, Kyrylo Tkachov wrote: > >> > >> > >> > >>> On 14 Oct 2024, at 15:28, Ricardo Jesus wrote: > >>> > >>> External email: Use caution opening links or attachment

Re: [PATCH] libstdc++: Avoid using std::__to_address with iterators

On Mon, 21 Oct 2024 at 18:02, François Dumont wrote: > > Reasoning is perfectly fine to me. > > It's not a good news for me cause I plan to extend usages of > __niter_base to many algos to limit impact of _GLIBCXX_DEBUG mode at > runtime. If we have random access iterator we can be sure that > __g

Re: [PATCH] libstdc++: Avoid using std::__to_address with iterators

Reasoning is perfectly fine to me. It's not a good news for me cause I plan to extend usages of __niter_base to many algos to limit impact of _GLIBCXX_DEBUG mode at runtime. If we have random access iterator we can be sure that __glibcxx_requires_valid_range fully validated the range and so we

Re: [WIP RFC] libstdc++: add module std

On 10/18/24 11:21 AM, Patrick Palka wrote: On Fri, 18 Oct 2024, Jason Merrill wrote: Is it useful for std.cc to live in a subdirectory of c++23 as in this patch, or should it be in c++23 itself? Or elsewhere? IIUC the src/ subdirectory is for stuff that gets compiled into the .so which isn't

Re: [PATCH] aarch64: libstdc++: Use shufflevector instead of shuffle in opt_random.h

On 10/14/24 14:37, Jonathan Wakely wrote: > > > On Mon, 14 Oct 2024 at 14:36, Kyrylo Tkachov wrote: >> >> >> >>> On 14 Oct 2024, at 15:28, Ricardo Jesus wrote: >>> >>> External email: Use caution opening links or attachments >>> >>> >>> This patch modifies the implementation of the vectorized m

Re: [PATCHv2 1/2] cfgexpand: Handle scope conflicts better [PR111422]

On Mon, Oct 21, 2024 at 3:41 AM Richard Biener wrote: > > On Thu, Oct 17, 2024 at 4:43 AM Andrew Pinski > wrote: > > > > After fixing loop-im to do the correct overflow rewriting > > for pointer types too. We end up with code like: > > ``` > > _9 = (unsigned long) &g; > > _84 = _9 + 18446744

Re: [PATCH] amdgcn: Refactor device settings into a def file

Hi Andrew, it it looks good at a glance. We surely will need add more columns in the future. In particular, I would add a new first column for the generic version, albeit currently unused; consider to include it already now.* Tobias (*) When eventually adding 'gfx-*-generic' support, more

RE: [PATCH 01/11] Match: Support form 1 for vector signed integer SAT_TRUNC

Thanks Richard for comments. > OK. Given almost all of the Saturation match pattern(s) are merged, I'd like to start the refinement about "common" match predictions to avoid duplication as we discussed in previous, after I draft the strided ld/st IFN patch(es). Pan -Original Message- F

[PATCH 2/2] Match: make SAT_ADD case 7 commutative

Case 7 of unsigned scalar saturating addition defines SAT_ADD = X <= (X + Y) ? (X + Y) : -1. This is the same as SAT_ADD = Y <= (X + Y) ? (X + Y) : -1 due to usadd_left_part_1 being commutative. The pattern for case 7 currently does not accept the alternative where Y is used in the condition. Ther

[PATCH 1/2] Match: support new case of unsigned scalar SAT_SUB

This patch adds a new case for unsigned scalar saturating subtraction using a branch with a greater-than-or-equal condition. For example, X >= (X - Y) ? (X - Y) : 0 is transformed into SAT_SUB (X, Y) when X and Y are unsigned scalars, which therefore correctly matches more cases of IFN SA

[PATCH 0/2] Match: support additional cases of unsigned scalar arithmetic

Hi all, This patch series adds support for 2 new cases of unsigned scalar saturating arithmetic (one addition, one subtraction). This results in more valid patterns being recognised, which results in a call to .SAT_ADD or .SAT_SUB where relevant. Regression tests for aarch64-none-linux-gnu all

Ping^2 [PATCH 0/2] Prime path coverage to gcc/gcov

Ping. On 10/10/24 10:08, Jørgen Kvalsvik wrote: Ping. On 10/3/24 12:46, Jørgen Kvalsvik wrote: This is both a ping and a minor update. A few of the patches from the previous set have been merged, but the big feature still needs review. Since then it has been quiet, but there are two notable c

[PATCH] amdgcn: Refactor device settings into a def file

I'm going to commit this soon, but I'd appreciate if anybody could have a quick look and let me know if anything is obviously broken or doing things the hard way, or something. Thanks! Andrew -- Almost all device-specific settings are now centralised into gcn-devices.def for the

[committed] amdgcn: silence warning

FIRST_SGPR_REG is register zero so the compiler always claims this comparison is redundant. It's right, of course, but I'd have preferred to keep the comparison for completeness. Probably the "correct" solution is to use an enum for these values. gcc/ChangeLog: * config/gcn/gcn.h (SGPR_

[committed v2] pair-fusion: Assume alias conflict if common address reg changes [PR116783]

This is a v2 of: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663600.html w.r.t. v1 this just implements Richard's suggestion of using safe_push as discussed here: https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665097.html Pushed to trunk after bootstrap + regtest (all languag

Re: [PATCH 02/11] Vect: Try the pattern of vector signed integer SAT_TRUNC

On Mon, Oct 14, 2024 at 1:12 PM wrote: > > From: Pan Li > > Almost the same as vector unsigned integer SAT_TRUNC, try to match > the signed version during the vector pattern matching. > > The below test suites are passed for this patch. > * The rv64gcv fully regression test. > * The x86 bootstrap

Re: [PATCH 01/11] Match: Support form 1 for vector signed integer SAT_TRUNC

On Mon, Oct 14, 2024 at 1:12 PM wrote: > > From: Pan Li > > This patch would like to support the form 1 of the vector signed > integer SAT_TRUNC. Aka below example: > > Form 1: > #define DEF_VEC_SAT_S_TRUNC_FMT_1(NT, WT, NT_MIN, NT_MAX) \ > void __attribute__((noinline))

[committed] libstdc++: Fix order of [[...]] and __attribute__((...)) attrs [PR117220]

Tested x86_64-linux, and briefly checked with Clang. Pushed to trunk. -- >8 -- GCC allows these in either order, but Clang doesn't like the C++11-style [[__nodiscard__]] coming after __attribute__((__always_inline__)). libstdc++-v3/ChangeLog: PR libstdc++/117220 * include/bits/s

[PATCH] c++/modules: Handle forward-declared class types

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- In some cases we can access members of a namespace-scope class without ever having performed name-lookup on it; this can occur when a forward-declaration of the class is used as a return type, for instance, or with PIMPL.

RE: [PATCH]middle-end: Handle more gcond lowering [PR117176]

On Mon, 21 Oct 2024, Tamar Christina wrote: > > -Original Message- > > From: Richard Biener > > Sent: Monday, October 21, 2024 9:55 AM > > To: Tamar Christina > > Cc: gcc-patches@gcc.gnu.org; nd > > Subject: Re: [PATCH]middle-end: Handle more gcond lowering [PR117176] > > > > On Mon, 2

Re: [PATCHv2 1/2] cfgexpand: Handle scope conflicts better [PR111422]

On Thu, Oct 17, 2024 at 4:43 AM Andrew Pinski wrote: > > After fixing loop-im to do the correct overflow rewriting > for pointer types too. We end up with code like: > ``` > _9 = (unsigned long) &g; > _84 = _9 + 18446744073709551615; > _11 = _42 + _84; > _44 = (signed char *) _11; > ... >

[PATCH v2 6/9] aarch64: Use symbols without offset to prevent relocation issues

Thursday, September 19, 2024 Richard Sandiford wrote: > abs_hwi (const_offset) (since const_offset has HOST_WIDE_INT type). abs_hwi has been applied. > It might be easier to pass base and const_offset from the caller > (aarch64_expand_mov_immediate). We are then guaranteed that the > offset is

Re: [PATCH 1/2] Match: Support IMM=max-1 for unsigned scalar .SAT_SUB IMM form 1

On Mon, Oct 21, 2024 at 5:09 AM Li Xu wrote: > > From: xuli > > This patch would like to support .SAT_SUB when one of the op > is IMM = max - 1 of form1. > > Form 1: > #define DEF_SAT_U_SUB_IMM_FMT_1(T, IMM) \ > T __attribute__((noinline)) \ > sat_u_sub_imm##IMM##_##T##_fmt_1 (T y)

RE: [PATCH]middle-end: Handle more gcond lowering [PR117176]

> -Original Message- > From: Richard Biener > Sent: Monday, October 21, 2024 9:55 AM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd > Subject: Re: [PATCH]middle-end: Handle more gcond lowering [PR117176] > > On Mon, 21 Oct 2024, Tamar Christina wrote: > > > Hi All, > > > > For

Re: [PATCH 1/2] Match: Support IMM=1 for unsigned scalar .SAT_SUB IMM form 1

On Mon, Oct 21, 2024 at 6:13 AM Li Xu wrote: > > From: xuli > > This patch would like to support .SAT_SUB when one of the op > is IMM = 1 of form1. > > Form 1: > #define DEF_SAT_U_SUB_IMM_FMT_1(T, IMM) \ > T __attribute__((noinline)) \ > sat_u_sub_imm##IMM##_##T##_fmt_1 (T y) \ >

[PATCH v2 9/9] aarch64: Handle alignment when it is bigger than BIGGEST_ALIGNMENT

Thursday, October 17, 2024 Richard Sandiford wrote: For instance: float __attribute__((aligned (32))) large_aligned_array[3]; BIGGEST_ALIGNMENT could be up to 512 bits on x64. This patch has been added to cover this case without needing to change the FFmpeg code. >>>

Re: [PATCH] phiopt: factor could move a trapping statement across other trapping statements [PR117235]

On Sun, Oct 20, 2024 at 7:01 PM Andrew Pinski wrote: > > After r15-4503-g8d6d6d537fdc75, phiopt could move a trapping statement > across another trapping statement causing the order to be incorrect (might > happen > with non-call exceptions). > To prevent this, a trapping statement has to be at t

Re: [PATCH] phiopt: do factor_out_conditional_operation for all phis [PR112418]

On Sat, Oct 19, 2024 at 5:08 PM Jeff Law wrote: > > > > On 10/18/24 7:41 PM, Andrew Pinski wrote: > > Sometimes factor_out_conditional_operation can factor out > > an operation that causes a phi node to become the same element. > > Other times, we want to factor out a binary operator because > > i

Re: [PATCH v2] MATCH: Simplify `(trunc)copysign ((extend)x, CST)` to `copysign (x, -1.0/1.0)` [PR112472]

On Wed, Oct 16, 2024 at 6:20 PM Eikansh Gupta wrote: > > This patch simplify `(trunc)copysign ((extend)x, CST)` to `copysign (x, > -1.0/1.0)` > depending on the sign of CST. Previously, it was simplified to `copysign (x, > CST)`. > It can be optimized as the sign of the CST matters, not the valu

Re: [PATCH v3] MATCH: Simplify `a rrotate (32-b) -> a lrotate b` [PR109906]

On Thu, Oct 17, 2024 at 11:06 AM Kyrylo Tkachov wrote: > > Hi Eikansh > > > On 16 Oct 2024, at 18:23, Eikansh Gupta wrote: > > > > The pattern `a rrotate (32-b)` should be optimized to `a lrotate b`. > > The same is also true for `a lrotate (32-b)`. It can be optimized to > > `a rrotate b`. > > >

Re: [PATCH]middle-end: Handle more gcond lowering [PR117176]

On Mon, 21 Oct 2024, Tamar Christina wrote: > Hi All, > > For boolean mask handling we have to lower BIT_NOT_EXPR for correctness into > BIT_XOR_EXPR. Normally this is done through vect_recog_bool_pattern by > following the defs of the gimple_assign. > > In the PR we ICE because early exits hav

Re: [PATCH] match.pd: Add std::pow folding optimizations.

On Fri, 18 Oct 2024, Jennifer Schmitz wrote: > This patch adds the following two simplifications in match.pd: > - pow (1.0/x, y) to pow (x, -y), avoiding the division > - pow (0.0, x) to 0.0, avoiding the call to pow. > The patterns are guarded by flag_unsafe_math_optimizations, > !flag_trapping_m

Re: [PATCH 2/7] libstdc++: Make __normal_iterator constexpr, always_inline, nodiscard

On Mon, 21 Oct 2024, 07:10 Stephan Bergmann, wrote: > Clang appears to be a bit picky wrt the relative order of annotation > notations here, and complains > Yes, this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117220 > > > /home/sberg/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/15.0.0/../../../