RE: [PATCH V2] RISC-V: Support LEN_FOLD_EXTRACT_LAST auto-vectorization

Committed, thanks Robin. Pan -Original Message- From: Gcc-patches On Behalf Of Robin Dapp via Gcc-patches Sent: Thursday, August 24, 2023 6:23 PM To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org Cc: rdapp@gmail.com; kito.ch...@gmail.com; kito.ch...@sifive.com; jeffreya...@gmail.com

[PATCH] PHIOPT: Add dump for match and simplify and early phiopt

This adds dump on the full result of the match-and-simplify for phiopt and specifically to know if we are rejecting something due to being in early phi-opt. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. gcc/ChangeLog: * tree-ssa-phiopt.cc (gimple_simplify_phiopt):

[PATCH] Fix phi-opt-34.c testcase

Somehow when I was testing the new testcase, it was working but when I re-ran the full testsuite it was not. Anyways the issue was just a simple space before the `}` for dg-options directive. Committed as obvious. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/phi-opt-34.c: Fix dg-options

Re: [PATCH] c++: tweaks for explicit conversion fns diagnostic

On 8/25/23 19:37, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- 1) When saying that a conversion is erroneous because it would use an explicit constructor, it might be nice to show where exactly the explicit constructor is located. For example,

Re: [Committed] RISC-V: Add Types to Un-Typed Sync Instructions:

On 8/25/2023 11:53 AM, Jeff Law via Gcc-patches wrote: On 8/24/23 15:19, Edwin Lu wrote: Related Discussion: https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/ This patch updates the sync instructions to ensure that no insn is left without a type

[PATCH] MAINTAINERS: Add myself to write after approval

* MAINTAINERS: Add myself Signed-off-by: Edwin Lu --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4e706df6522..da2817a547c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -541,6 +541,7 @@ Gabor Loki

[PATCH] c++: tweaks for explicit conversion fns diagnostic

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- 1) When saying that a conversion is erroneous because it would use an explicit constructor, it might be nice to show where exactly the explicit constructor is located. For example, with this patch: [...] explicit.C:4:12:

Re: [PATCH 3/3] PHIOPT: Allow BIT_AND and BIT_IOR in early phiopt

On Thu, Aug 24, 2023 at 11:47 PM Richard Biener via Gcc-patches wrote: > > On Thu, Aug 24, 2023 at 9:16 PM Andrew Pinski via Gcc-patches > wrote: > > > > Now that MIN/MAX can sometimes be transformed into BIT_AND/BIT_IOR, > > we should allow BIT_AND and BIT_IOR in the early phiopt. > > Also we

[committed] RISC-V: Make stack_save_restore tests more robust

Spurred by Jivan's patch and a desire for cleaner testresults, I went ahead and make the stack_save_restore tests independent of the precise stack size by using a regexp. Pushed to the trunk. Jeffcommit e1f096a3cc96c71907cfbc7b8baf67a3d863cb6d Author: Jeff Law Date: Fri Aug 25 16:34:17

[committed] RISC-V: Fix minor testsuite problem with zicond

I thought I had already fixed this, but clearly if I did, I didn't include it in any upstream commits. With -Og the optimizers are hindered in various ways and this prevents using zicond. So skip this test with -Og (it was already being skipped at -O0). Pushed to the trunk. Jeff commit

Re: [PATCH] rs6000: Disable PCREL for unsupported targets [PR111045]

On 8/25/23 6:20 AM, Kewen.Lin wrote: > Assuming the current PCREL_SUPPORTED_BY_OS unchanged, when > PCREL_SUPPORTED_BY_OS is true, all its required conditions are > satisfied, it should be safe. while PCREL_SUPPORTED_BY_OS is > false, it means the given subtarget doesn't support it, or one > or

Re: [PATCH v10] RISC-V: Add support for the Zfa extension

On 8/13/23 23:50, Jin Ma wrote: This patch adds the 'Zfa' extension for riscv, which is based on: https://github.com/riscv/riscv-isa-manual/commits/zfb The binutils-gdb for 'Zfa' extension: https://sourceware.org/pipermail/binutils/2023-April/127060.html What needs special explanation is:

Re: [2/2] RISC-V: Constant FP Optimization with 'Zfa'

On 8/14/23 06:51, Jin Ma wrote: This code is great and completely different from the way I implemented it. I'm not sure which one is better, but my idea is that the fli instruction corresponds to three tables (HF, SF and DF), all of which represent specific values. the library in gcc's

[PATCH] c++: Implement C++26 P1854R4 - Making non-encodable string literals ill-formed [PR110341]

Hi! This paper voted in as DR makes some multi-character literals ill-formed. 'abcd' stays valid, but e.g. 'á' is newly invalid in UTF-8 exec charset while valid e.g. in ISO-8859-1, because it is a single character which needs 2 bytes to be encoded. The following patch does that by checking

Re: [PATCH] libgccjit: Add support for `restrict` attribute on function parameters

After more investigations, it seems like the fault was on our side as we were calling `gcc_jit_type_get_restrict` on types that weren't pointers. I added a check for that in `gcc_jit_type_get_restrict` directly as well. We will continue our investigation to be sure we didn't miss anything. Le

[PATCH] testsuite: Add test for already-fixed issue with _Pragma expansion [PR90400]

Hello- This is adding a testcase for a PR that was already incidentally fixed. OK to commit please? Thanks... -Lewis -- >8 -- The PR was fixed by r12-5454. Since the fix was somewhat incidental, although related, add a testcase from PR90400 too before closing it out. gcc/testsuite/ChangeLog:

[PATCH] c++: Implement C++ DR 2406 - [[fallthrough]] attribute and iteration statements

Hi! The following patch implements CWG 2406 - [[fallthrough]] attribute and iteration statements The genericization of some loops leaves nothing at all or just a label after a body of a loop, so if the loop is later followed by case or default label in a switch, the fallthrough statement isn't

Re: [PATCH 1/2] RISC-V: Add support for the 'Zfa' extension

On 8/13/23 23:32, Tsukasa OI via Gcc-patches wrote: From: Tsukasa OI This commit adds support for the 'Zfa' extension containing additional floating point instructions, version 0.1 (stable and approved). gcc/ChangeLog: * common/config/riscv/riscv-common.cc

Re: [PATCH] analyzer: Move gcc.dg/analyzer tests to c-c++-common (1).

On Fri, 2023-08-25 at 14:48 +0200, Benjamin Priour wrote: > Hi David, > > Thanks for the review. > > On Fri, Aug 25, 2023 at 2:12 AM David Malcolm > wrote: > > > > From: benjamin priour > > > > > > Hi, > > > > > > Below the first batch of a serie of patches to transition > > > the analyzer

Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

th 201 annotations[1] added. Things work as expected. :) -Kees [1] https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=devel/next-20230825/counted_by -- Kees Cook

[COMMITTED V3 5/6] OpenMP: Fortran support for imperfectly-nested loops

OpenMP 5.0 removed the restriction that multiple collapsed loops must be perfectly nested, allowing "intervening code" (including nested BLOCKs) before or after each nested loop. In GCC this code is moved into the inner loop body by the respective front ends. In the Fortran front end, most of

[COMMITTED V3 4/6] OpenMP: New C/C++ testcases for imperfectly nested loops.

gcc/testsuite/ChangeLog * c-c++-common/gomp/imperfect-attributes.c: New. * c-c++-common/gomp/imperfect-badloops.c: New. * c-c++-common/gomp/imperfect-blocks.c: New. * c-c++-common/gomp/imperfect-extension.c: New. * c-c++-common/gomp/imperfect-gotos.c: New.

[COMMITTED V3 2/6] OpenMP: C front end support for imperfectly-nested loops

OpenMP 5.0 removed the restriction that multiple collapsed loops must be perfectly nested, allowing "intervening code" (including nested BLOCKs) before or after each nested loop. In GCC this code is moved into the inner loop body by the respective front ends. This patch changes the C front end

[COMMITTED V3 6/6] OpenMP: Document support for imperfectly-nested loops.

libgomp/ChangeLog * libgomp.texi (OpenMP 5.0): Imperfectly-nested loops are done. --- libgomp/libgomp.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi index 5c91163893f..4aad8cc52f4 100644 --- a/libgomp/libgomp.texi +++

[COMMITTED V3 3/6] OpenMP: C++ support for imperfectly-nested loops

OpenMP 5.0 removed the restriction that multiple collapsed loops must be perfectly nested, allowing "intervening code" (including nested BLOCKs) before or after each nested loop. In GCC this code is moved into the inner loop body by the respective front ends. This patch changes the C++ front end

[COMMITTED V3 1/6] OpenMP: Add OMP_STRUCTURED_BLOCK and GIMPLE_OMP_STRUCTURED_BLOCK.

In order to detect invalid jumps in and out of intervening code in imperfectly-nested loops, the front ends need to insert some sort of marker to identify the structured block sequences that they push into the inner body of the loop. The error checking happens in the diagnose_omp_blocks pass,

[COMMITTED V3 0/6] Support for imperfectly-nested loops

V2 of these patches were previously approved with a few small changes requested. For the archives, here is the version I've pushed. Parts 1 and 2 are unchanged since V2. In part 3 (C++) I had to fix a merge problem by hand. In parts 4 and 5, I hacked up a couple tests as requested by Jakub.

[Committed] RISC-V: Enable Hoist to GCSE simple constants

Hoist want_to_gcse_p () calls rtx_cost () to compute max distance for hoist candidates. For a simple const (say 6 which needs seperate insn "LI 6") backend currently returns 0, causing Hoist to bail and elide GCSE. Note that constants requiring more than 1 insns to setup were working fine since

Re: [PATCH V2] RISC-V: Add Types to Un-Typed Sync Instructions:

On 8/24/23 15:19, Edwin Lu wrote: Related Discussion: https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/ This patch updates the sync instructions to ensure that no insn is left without a type attribute. Updates a total of 6 insns to have type "atomic"

Re: [PATCH v2] RISC-V: Enable Hoist to GCSE simple constants

On 8/24/23 23:16, Vineet Gupta wrote: Hoist want_to_gcse_p () calls rtx_cost () to compute max distance for hoist candidates. For a simple const (say 6 which needs seperate insn "LI 6") backend currently returns 0, causing Hoist to bail and elide GCSE. Note that constants requiring more than

Re: RISC-V: Fix stack_save_restore_1/2 test cases

On 8/24/23 09:45, Jivan Hakobyan via Gcc-patches wrote: Subject: RISC-V: Fix stack_save_restore_1/2 test cases From: Jivan Hakobyan via Gcc-patches Date: 8/24/23, 09:45 To: GCC Patches , Jeff Law This patch fixes failing stack_save_restore_1/2 test cases. After 6619b3d4c15c commit size

[COMMITTEDv2] MATCH: Move `a ? one_zero : one_zero` matching after min/max matching

In PR 106677, I noticed that on the trunk we were producing: ``` _25 = SR.116_117 == 0; _27 = (unsigned char) _25; _32 = _27 | SR.116_117; ``` >From `SR.115_117 != 0 ? SR.115_117 : 1` Rather than: ``` _119 = MAX_EXPR <1, SR.115_117>; ``` Or (rather) ``` _119 = SR.115_117 | 1; ``` Due to

Re: [PATCH 1/3] MATCH: Move `a ? one_zero : one_zero` matching after min/max matching

On Fri, Aug 25, 2023 at 11:11 AM Andrew Pinski wrote: > > On Thu, Aug 24, 2023 at 11:39 PM Richard Biener via Gcc-patches > wrote: > > > > On Thu, Aug 24, 2023 at 9:16 PM Andrew Pinski via Gcc-patches > > wrote: > > > > > > In PR 106677, I noticed that on the trunk we were producing: > > > ```

[wwwdocs] projects/gomp: Update implementation status and minor fixes

This syncs the libgomp.texi implementation status to the webpage, i.e. adding a few new items + marking some as 'supported'. It also fixes a couple of bugs and adds links providing more details for two items (a PR link as in libgomp.texi and a section in the manual). Comments? Suggestions? If

Re: [PATCH 1/3] MATCH: Move `a ? one_zero : one_zero` matching after min/max matching

On Thu, Aug 24, 2023 at 11:39 PM Richard Biener via Gcc-patches wrote: > > On Thu, Aug 24, 2023 at 9:16 PM Andrew Pinski via Gcc-patches > wrote: > > > > In PR 106677, I noticed that on the trunk we were producing: > > ``` > > _25 = SR.116_117 == 0; > > _27 = (unsigned char) _25; > > _32 =

Re: [PATCH] c++: CWG 2359, wrong copy-init with designated init [PR91319]

On Fri, 25 Aug 2023, Marek Polacek via Gcc-patches wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? LGTM > > -- >8 -- > > This CWG clarifies that designated initializer support direct-initialization. > Just be careful what Note 2 in [dcl.init.aggr]/4.2 says: "If the >

[PATCH] c++: more dummy non_constant_p arg avoidance

Tested on x86_64-pc-linux-gnu, does this look OK for trunk? This reduces calls to is_rvalue_constant_expression from cp_parser_constant_expression by 10% for stdc++.h. -- >8 -- As a follow-up to Marek's r14-3088-ga263152643bbec, this patch makes us avoid passing an effectively dummy

Re: [PATCH] c++: use conversion_obstack_sentinel throughout

On Fri, Aug 25, 2023 at 12:33:31PM -0400, Patrick Palka via Gcc-patches wrote: > Boostrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > trunk? Very nice. LGTM. > -- >8 -- > > This replaces manual memory management via conversion_obstack_alloc(0) > and obstack_free with the

[PATCH] c++: CWG 2359, wrong copy-init with designated init [PR91319]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This CWG clarifies that designated initializer support direct-initialization. Just be careful what Note 2 in [dcl.init.aggr]/4.2 says: "If the initialization is by designated-initializer-clause, its form determines whether

[PATCH] c++: use conversion_obstack_sentinel throughout

Boostrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- This replaces manual memory management via conversion_obstack_alloc(0) and obstack_free with the recently added conversion_obstack_sentinel, and also uses the latter in build_user_type_conversion and

Re: Darwin: Replace environment runpath with embedded [PR88590]

On Fri, 25 Aug 2023, FX Coudert via Gcc-patches wrote: > Hi, > > Thanks Joseph for the review. > > > The driver changes are OK. > > > > I think the new configure options and the new -nodefaultrpaths compiler > > option need documenting > > Doc patch was added, and okay’ed by Iain. I see

[PATCH] MATCH: Move `(X & ~Y) | (~X & Y)` over to use bitwise_inverted_equal_p

This moves the pattern `(X & ~Y) | (~X & Y)` to use bitwise_inverted_equal_p so we can simplify earlier the case where X and Y are defined by comparisons. We were able to optimize to (!X)^(!Y) in the end due to the pattern added in r14-3110-g7fb65f102851248bafa0815 and the older pattern

[V3][PATCH 3/3] Use the counted_by attribute information in bound sanitizer[PR108896]

Use the counted_by attribute information in bound sanitizer. gcc/c-family/ChangeLog: PR C/108896 * c-ubsan.cc (ubsan_instrument_bounds): Use counted_by attribute information. gcc/testsuite/ChangeLog: PR C/108896 *

[V3][PATCH 2/3] Use the counted_by atribute info in builtin object size [PR108896]

Use the counted_by atribute info in builtin object size to compute the subobject size for flexible array members. gcc/ChangeLog: PR C/108896 * tree-object-size.cc (addr_object_size): Use the counted_by attribute info. * tree.cc (component_ref_has_counted_by_p):

[V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

This is the 3rd version of the patch, per our discussion based on the review comments for the 1st and 2nd version, the major changes in this version are: ***Against 1st version: 1. change the name "element_count" to "counted_by"; 2. change the parameter for the attribute from a STRING to an

[V3][PATCH 1/3] Provide counted_by attribute to flexible array member field (PR108896)

Provide a new counted_by attribute to flexible array member field. 'counted_by (COUNT)' The 'counted_by' attribute may be attached to the flexible array member of a structure. It indicates that the number of the elements of the array is given by the field named "COUNT" in the

Re: [RFC] -folding dumping for fold-const.cc

On Fri, 25 Aug 2023, Richard Biener via Gcc-patches wrote: > > The following adds the capability to have fold-const.cc matched > patterns visible in -folding dumps. There's two choices, > a portable one replacing return stmts like > > - return fold_build1 (tcode, ctype, fold_convert

[RFC] -folding dumping for fold-const.cc

The following adds the capability to have fold-const.cc matched patterns visible in -folding dumps. There's two choices, a portable one replacing return stmts like - return fold_build1 (tcode, ctype, fold_convert (ctype, t1)); + DRET (fold_build1 (tcode, ctype, fold_convert (ctype,

Re: [PATCH] analyzer: Move gcc.dg/analyzer tests to c-c++-common (1).

Hi David, Thanks for the review. On Fri, Aug 25, 2023 at 2:12 AM David Malcolm wrote: > > From: benjamin priour > > > > Hi, > > > > Below the first batch of a serie of patches to transition > > the analyzer testsuite from gcc.dg/analyzer to c-c++-common/analyzer. > > I do not know how long

RE: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook

Hi Jeff, > You might also peek at the RTL gcse/pre code which is also LCM based and > has the same class of problems. I found a similar approach to take care of this in gcse.cc/pre_edge_insert with some comments as below. /* We can't insert anything on an abnormal and critical edge,

[pushed] analyzer: fix ICE in text art strings support

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r14-3481-g99a3fcb8ff0bf2. gcc/analyzer/ChangeLog: * access-diagram.cc (class string_region_spatial_item): Remove assumption that the string is written to the start of the cluster.

[PATCH] tree-optimization/111137 - dependence checking for SLP

The following fixes a mistake with SLP dependence checking. When checking whether we can hoist loads to the first load place we special-case stores of the same instance considering them sunk to the last store place. But we fail to consider that stores from other SLP instances are sunk in a

Re: [PATCH] rs6000: Disable PCREL for unsupported targets [PR111045]

on 2023/8/25 11:20, Peter Bergner wrote: > On 8/24/23 12:56 AM, Kewen.Lin wrote: >> By looking into the uses of function rs6000_pcrel_p, I think we can >> just replace it with TARGET_PCREL. Previously we don't require PCREL >> unset for any unsupported target/OS, so we need rs6000_pcrel_p() to >>

[PATCH] Apply some TLC to vect_slp_analyze_instance_dependence

This refactors things, separating load and store handing, adjusting comments to reflect reality and removing some dead code. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. This is in preparation for a fix for PR37. * tree-vect-data-refs.cc

[PATCH v2] LoongArch: Remove redundant sign extension instructions caused by SLT instructions.

v1 -> v2: 1. Modify description information Since the SLT instruction does not distinguish between 64-bit operations and 32-bit operations under the 64-bit LoongArch architecture, if the operand of slt is SImode, the sign extension of the operand needs to be displayed. But similar to

Re: [PATCH] fortran: Rename TRUE/FALSE to true/false in *.cc files

On 25.08.23 10:26, Uros Bizjak via Gcc-patches wrote: gcc/fortran/ChangeLog: * match.cc (gfc_match_equivalence): Rename TRUE/FALSE to true/false. * module.cc (check_access): Ditto. * primary.cc (match_real_constant): Ditto. * trans-array.cc

[PATCH] fortran: Rename TRUE/FALSE to true/false in *.cc files

gcc/fortran/ChangeLog: * match.cc (gfc_match_equivalence): Rename TRUE/FALSE to true/false. * module.cc (check_access): Ditto. * primary.cc (match_real_constant): Ditto. * trans-array.cc (gfc_trans_allocate_array_storage): Ditto. (get_array_ctor_strlen): Ditto. *

[committed] treewide: Rename TRUE/FALSE to true/false in *.cc files

gcc/c-family/ChangeLog: * c-format.cc (read_any_format_width): Rename TRUE/FALSE to true/false. gcc/ChangeLog: * caller-save.cc (new_saved_hard_reg): Rename TRUE/FALSE to true/false. (setup_save_areas): Ditto. * gcc.cc (set_collect_gcc_options): Ditto.

Re: RISC-V: Fix stack_save_restore_1/2 test cases

Hi Vineet. Do you mind sending your patches inline using git send-email or some such ? Never thought about that, what is the purpose of sending it in that way? Of course, if it is more convenient for the community then I will send through git. On Fri, Aug 25, 2023 at 9:12 AM Vineet Gupta

[PATCH] tree-optimization/111136 - STMT_VINFO_SLP_VECT_ONLY and stores

vect_dissolve_slp_only_groups currently only expects loads, for stores we have to make sure to mark the dissolved "groups" strided. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. PR tree-optimization/36 * tree-vect-loop.cc (vect_dissolve_slp_only_groups): For

[PATCH] RISC-V: Refactor and clean expand_cond_len_{unop, binop, ternop}

Hi, This patch refactors the codes of expand_cond_len_{unop,binop,ternop}. Introduces a new unified function expand_cond_len_op to do the main thing. The expand_cond_len_{unop,binop,ternop} functions only care about how to pass the operands to the intrinsic patterns. Best, Lehua gcc/ChangeLog:

Re: [PATCH 2/3] MATCH: `a | C -> C` when we know that `a & ~C == 0`

On Thu, Aug 24, 2023 at 11:37 PM Richard Biener via Gcc-patches wrote: > > On Thu, Aug 24, 2023 at 9:16 PM Andrew Pinski via Gcc-patches > wrote: > > > > Even though this is handled by other code inside both VRP and CCP, > > sometimes we want to optimize this outside of VRP and CCP. > > An

Re: [PATCH V2] RISC-V: Add conditional autovec convert(INT<->INT) patterns

Hi Robin, There is one issue with this patch and the next few patches, the mask policy for the generated vsetvl should be mu, which is currently done wrong. I'm going to clear the expand_cond_len* functions before sending the next version of these patches. Then these patches can directly use

MIPS: the method of getting GOT address for PIC code

When working on LLVM, I found this problem https://github.com/llvm/llvm-project/issues/64974. Maybe it's time for us to reconsider the way of getting GOT address for PIC code. 1.Background[1]: All of the accessing of global variables and normal function calls needs help from GOT. So normally, the

Re: [PATCH V2] RISC-V: Add conditional autovec convert(INT<->INT) patterns

Hi Lehua, thanks, LGTM. One thing maybe for the next patches: It seems to me that we lump all of the COND_... tests into the cond subdirectory when IMHO they would also fit into the respective directories of their operations (binop, unop etc). Right now we will have a lot of rather unrelated

Re: [PATCH 3/3] PHIOPT: Allow BIT_AND and BIT_IOR in early phiopt

On Thu, Aug 24, 2023 at 9:16 PM Andrew Pinski via Gcc-patches wrote: > > Now that MIN/MAX can sometimes be transformed into BIT_AND/BIT_IOR, > we should allow BIT_AND and BIT_IOR in the early phiopt. > Also we produce BIT_AND/BIT_IOR for things like `bool0 ? bool1 : 0` > which seems like a good

[PATCH-2, rs6000] Implement 32bit inline lrint [PR88558]

Hi, This patch implements 32bit inline lrint by "fctiw". It depends on the patch1 to do SImode move from FP register on P7. Bootstrapped and tested on powerpc64-linux BE and LE with no regressions. Thanks Gui Haochen ChangeLog rs6000: support 32bit inline lrint gcc/ PR target/88558

[PATCH-1, rs6000] Enable SImode in FP register on P7 [PR88558]

Hi, This patch enables SImode in FP register on P7. Instruction "fctiw" stores its integer output in an FP register. So SImode in FP register needs be enabled on P7 if we want support "fctiw" on P7. The test case is in the second patch which implements 32bit inline lrint. Bootstrapped and

Re: [PATCH 1/3] MATCH: Move `a ? one_zero : one_zero` matching after min/max matching

On Thu, Aug 24, 2023 at 9:16 PM Andrew Pinski via Gcc-patches wrote: > > In PR 106677, I noticed that on the trunk we were producing: > ``` > _25 = SR.116_117 == 0; > _27 = (unsigned char) _25; > _32 = _27 | SR.116_117; > ``` > From `SR.115_117 != 0 ? SR.115_117 : 1` > Rather than: > ``` >

Re: [PATCH 2/3] MATCH: `a | C -> C` when we know that `a & ~C == 0`

On Thu, Aug 24, 2023 at 9:16 PM Andrew Pinski via Gcc-patches wrote: > > Even though this is handled by other code inside both VRP and CCP, > sometimes we want to optimize this outside of VRP and CCP. > An example is given in PR 106677 where phiopt will happen > after VRP (which removes a cast

Re: [PATCH v1] LoongArch: Remove the symbolic extension instruction due to the SLT directive.

在 2023/8/25 下午12:16, WANG Xuerui 写道: On 8/25/23 12:01, Lulu Cheng wrote: Since the slt instruction does not distinguish between 32-bit and 64-bit operations under the LoongArch 64-bit architecture, if the operands of slt are of SImode, symbol expansion is required before operation.