Re: [PATCH, rs6000] Add non-relative jump table support on Power Linux

05PM +0800, HAO CHEN GUI wrote: This patch adds non-relative jump table support on Power Linux. It implements ASM_OUTPUT_ADDR_VEC_ELT and adds four new expansions for non-relative jump table in rs6000.md. It also defines a rs6000 option(mrelative-jumptables). If it's set to false, the non-rela

Re: [PATCH] Add support for putting jump table into relocation read-only section

; On 17/8/2020 下午 10:50, Segher Boessenkool wrote: Hi! On Mon, Aug 17, 2020 at 10:28:31AM +0800, HAO CHEN GUI wrote: For the reloc,  my understanding is the jump table needs to be relocated if it's a non-relative jump table and PIC flag is set at the same time. Yes, I did say the *existi

Do we need to do a loop invariant motion after loop interchange ?

Hi, I want to follow Lijia's work as I gained the performance benefit on some SPEC workloads by adding a im pass after loop interchange.  Could you send me the latest patches? I could do further testing. Thanks a lot. https://gcc.gnu.org/pipermail/gcc/2020-February/232091.html

Re: [PATCH, rs6000] Add non-relative jump table support on Power Linux

. On 8/9/2020 上午 5:46, Segher Boessenkool wrote: On Mon, Aug 24, 2020 at 03:48:43PM +0800, HAO CHEN GUI wrote: I'll try to be quicker at reviewing iterations of this -- there is quite some way to go, without me slowing things down! Sigh :-( * config/rs6000/li

[PATCH, rs6000] Add non-relative jump table support for 64bit rs6000

Hi, This patch adds non-relative jump table support for 64bit rs6000. It implements ASM_OUTPUT_ADDR_VEC_ELT and corresponding expansion of jump table instruction for 64bit rs6000. We want to put non-relative jump table in data.rel.ro section for rs6000. So I add a new target hook - TARGET_ASM

[PATCH, rs6000] Add non-relative jump table support for 64bit rs6000

David, Seems there is something wrong with my email box.  I lost your email. I reconfigured the box and it should be OK now. Could you inform me how to exclude AIX from the condition testing? By the ABI? Thanks a lot. Haochen Gui

Re: [PATCH] Add a new pattern in 4-insn combine

Segher,     Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560573.html On 30/11/2020 上午 11:08, HAO CHEN GUI wrote: Hi,   This patch adds a new pattern(combine 4 insns to 3 insns) in 4-insn combine. In the patch, newpat is split twice. The newpat, newi2pat and

Re: [PATCH] Add a new pattern in 4-insn combine

Segher,     Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560573.html Thanks a lot. On 11/12/2020 上午 10:14, HAO CHEN GUI wrote: Segher,     Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560573.html

Re: [PATCH] Add a new pattern in 4-insn combine

Segher,     Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560573.html Thanks a lot. On 4/1/2021 上午 10:03, HAO CHEN GUI wrote: Segher,     Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560573.html Thanks a lot. On 11/12/2020 上午 10

Re: [PATCH, rs6000] Add non-relative jump table support on Power Linux

Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556236.html Thanks. Gui Haochen On 6/11/2020 上午 9:02, HAO CHEN GUI wrote: Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556236.html Thanks. Gui Haochen On 15/10/2020 下午 4:46

Re: [PATCH, rs6000] Add non-relative jump table support on Power Linux

Segher,   Thanks for your comments. I have modified the patch according to your advice and committed. On 24/11/2020 上午 6:25, Segher Boessenkool wrote: Hi! Sorry this took so long. On Thu, Oct 15, 2020 at 04:46:01PM +0800, HAO CHEN GUI wrote: On 29/9/2020 上午 6:46, Segher Boessenkool wrote

[PATCH] Add a new pattern in 4-insn combine

Hi,   This patch adds a new pattern(combine 4 insns to 3 insns) in 4-insn combine. In the patch, newpat is split twice. The newpat, newi2pat and newi1pat replace i3, i2 and i1 respectively. The 4 to 3 combine is done at the end where all former attempts fail. In 4 insn combine pre-check, the

Re: [PATCH, rs6000] Add non-relative jump table support on Power Linux

Boessenkool wrote: Hi hao Chen, On Wed, Sep 09, 2020 at 04:55:29PM +0800, HAO CHEN GUI wrote:     Thanks for your advice. I removed macros defined in linux64.h and linux.h. So they take relative jump tables by default. When no-relative-jumptables is set, the absolute jump tables are taken. All

Re: [PATCH] Put absolute address jump table in data.rel.ro.local if targets support relocations

I had a wrong email setting and got your reply later. I modified the patch according to your advice. Could you please review it again? Thanks. On 2/10/2020 上午 1:47, Richard Sandiford wrote: Sorry for the slow review. HAO CHEN GUI via Gcc-patches writes: diff --git a/gcc/config/mips/mips.c b

[PATCH v4, rs6000] Change mode and insn condition for VSX scalar extract/insert instructions

Hi, For scalar extract/insert instructions, exponent field can be stored in a 32-bit register. So this patch changes the mode of exponent field from DI to SI. So these instructions can be generated in a 32-bit environment. The patch removes TARGET_64BIT check for these instructiions. The instr

[rs6000, patch] Enable have_cbranchcc4 on rs6000

Hi, The patch enables have_cbrnachcc4 which is a flag in ifcvt.cc to indicate if branch by CC bits is invalid or not. As rs6000 already has "*cbranch" insn which does branching according to CC bits, the flag should be enabled and relevant branches can be optimized out. The test case illustrates t

Re: [rs6000, patch] Enable have_cbranchcc4 on rs6000

Hi David, I found definition of the operands in 'cbranch'. The argumnets matters. I will create a new expand pattern for cbranchcc4. Thanks a lot for your comments. 'cbranchmode4’ Conditional branch instruction combined with a compare instruction. Operand 0 is a comparison operator. Operand 1 an

[PATCHv2, rs6000] Enable have_cbranchcc4 on rs6000

Hi, The patch enables have_cbrnachcc4 which is a flag in ifcvt.cc to indicate if branch by CC bits is invalid or not. The new expand pattern "cbranchcc4" is created which intend to match the pattern defined in "*cbranch", "*cbranch_2insn" and "*creturn". The operand sequence in "cbranchcc4" is in

Re: [PATCHv2, rs6000] Enable have_cbranchcc4 on rs6000

Hi David, 在 2022/11/17 21:24, David Edelsohn 写道: > This is better, but the pattern should be near and after the existing > cbranch4 patterns earlier in the file, not the *cbranch pattern.  It > doesn't match the comment. Sure, I will put it after existing "cbranch4" patterns. > > Why are you u

[PATCH 2/1, rs6000] make ppc_cpu_supports_hw as effective target keyword [PR108728]

Hi, This patch adds ppc_cpu_supports_hw into explicit name checking in proc is-effective-target-keyword. So ppc_cpu_supports_hw can be used as a target selector in test directives. It's required by patch2 of this issue. Thanks Gui Haochen ChangeLog testsuite: make ppc_cpu_supports_hw as effecti

[PATCH 2/2, rs6000] xfail float128 comparison test case that fails on powerpc64 [PR108728]

Hi, This patch xfails a float128 comparison test case on powerpc64 that fails due to a longstanding issue with floating-point compares. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684 for more information. The patch passed regression test on Power Linux platforms. Thanks Gui Haochen

PING^2 [PATCH, rs6000] Splat vector small V2DI constants with ISA 2.07 instructions [PR104124]

Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601909.html Thanks Gui Haochen 在 2022/12/14 13:30, HAO CHEN GUI 写道: > Hi, >Gentle ping this: > https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601909.html > > Thanks > Gui Haochen &

Ping [PATCH-1, rs6000] Change mode and insn condition for scalar extract exp instruction

Hi, Gently ping this. https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609369.html Thanks Gui Haochen 在 2023/1/4 14:16, HAO CHEN GUI 写道: > Hi, > This patch changes the return type of __builtin_vsx_scalar_extract_exp > from const signed long to const signed int, as the expone

Ping [PATCH-2, rs6000] Change mode and insn condition for scalar extract sig instruction

Hi, Gently ping this. https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609370.html Thanks Gui Haochen 在 2023/1/4 14:16, HAO CHEN GUI 写道: > Hi, > This patch changes the return type of __builtin_vsx_scalar_extract_sig > from const signed long to const signed long long, so that

Re: [PATCH-3, rs6000] Change mode and insn condition for scalar insert exp instruction

Hi, Gently ping this. https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609371.html Thanks Gui Haochen 在 2023/1/4 14:17, HAO CHEN GUI 写道: > Hi, > This patch changes the mode of exponent to GPR in scalar insert exp > pattern, as the exponent can be put into a 32-bit register.

Re: [PATCH-4, rs6000] Change ilp32 target check for some scalar-extract-sig and scalar-insert-exp test cases

Hi, Gently ping this. https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609372.html Thanks Gui Haochen 在 2023/1/4 14:17, HAO CHEN GUI 写道: > Hi, > "ilp32" is used in these test cases to make sure test cases only run on a > 32-bit environment. Unfortunately, these

Ping^2 [PATCH, rs6000] Split TImode for logical operations in expand pass [PR100694]

Hi, Gently ping this: https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611550.html Thanks Gui Haochen 在 2023/2/20 10:10, HAO CHEN GUI 写道: > Hi, > Gently ping this: > https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611550.html > > Gui Haochen > Thanks >

Ping [PATCHv2, rs6000] Merge two vector shift when their sources are the same

Hi Gently ping this. https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612944.html Thanks Gui Haochen 在 2023/2/28 10:31, HAO CHEN GUI 写道: > Hi, > This patch merges two "vsldoi" insns when their sources are the > same. Particularly, it is simplified to be one move i

[PATCHv2, rs6000] Splat vector small V2DI constants with ISA 2.07 instructions [PR104124]

Hi, This patch adds a new insn for vector splat with small V2DI constants on P8. If the value of constant is in RANGE (-16, 15) and not 0 or -1, it can be loaded with vspltisw and vupkhsw on P8. It should be efficient than loading vector from TOC. Compared to last version, the main change is t

[PATCH, rs6000] Split TImode for logical operations in expand pass [PR100694]

Hi, The logical operations for TImode is split after reload pass right now. Some potential optimizations miss as the split is too late. This patch removes TImode from "AND", "IOR", "XOR" and "NOT" expander so that these logical operations can be split at expand pass. The new test case illustrates

Re: [PATCH v4, rs6000] Add V1TI into vector comparison expand [PR103316]

check then? On 26/5/2022 上午 11:22, Kewen.Lin wrote: > Hi Haochen, > > on 2022/5/24 16:45, HAO CHEN GUI wrote: >> Hi, >>This patch adds V1TI mode into a new mode iterator used in vector >> comparison and rotation expands. Without the patch, the comparisons >>

[PATCH v2, rs6000] Fix ICE on expand bcd__ [PR100736]

Hi, This patch fixes the ICE reported in PR100736. It removes the condition check of finite math only flag not setting in "*_cc" pattern. With or without this flag, we still can use "cror" to check if either two bits of CC is set or not for "fp_two" codes. We don't need a reverse comparison (impl

Ping [PATCH v3, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]

Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595164.html Thanks. On 18/5/2022 下午 4:52, HAO CHEN GUI wrote: > Hi, > This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000. > Tests show that outputs of xs[min/max]dp are consistent with the

Ping [PATCH v2, rs6000] Fix ICE on expand bcd__ [PR100736]

Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595661.html Thanks. On 26/5/2022 下午 3:35, HAO CHEN GUI wrote: > Hi, > This patch fixes the ICE reported in PR100736. It removes the condition > check of finite math only flag not setting in "*_cc"

[PATCH v5, rs6000] Add V1TI into vector comparison expand [PR103316]

Hi, This patch adds V1TI mode into a new mode iterator used in vector comparison shift and rotation expands. Without the patch, the comparisons between two vector __int128 are converted to scalar comparisons and code is suboptimal. The patch fixes the issue. Now all comparisons between two vecto

Re: [PATCH v2, rs6000] Fix ICE on expand bcd__ [PR100736]

Segher, Does BCD comparison return false when either operand is invalid coding? If yes, the result could be 3-way. We can check gt and eq bits for ge. We still can't use crnot to only check lt bit as there could be invalid coding. Also, do you think finite-math-only excludes invalid coding? See

[PATCH-1, rs6000] Replace shift and ior insns with one rotate and mask insn for bswap pattern [PR93453]

Hi, This patch replaces shift and ior insns with one rotate and mask insn for the split patterns which are for DI byte swap on Power6 and before. The test cases shows the optimization. Bootstrapped and tested on ppc64 Linux BE and LE with no regressions. Is this okay for trunk? Any recommendat

Re: [PATCH v2, rs6000] Fix ICE on expand bcd__ [PR100736]

On 2/6/2022 下午 5:04, Segher Boessenkool wrote: > Hi! > > On Thu, Jun 02, 2022 at 01:30:04PM +0800, HAO CHEN GUI wrote: >> Segher, >> Does BCD comparison return false when either operand is invalid coding? > > It sets all of LT, GT, and EQ to 0 (it normally sets

Re: [PATCH v3, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]

Hi, On 2/6/2022 上午 5:01, Segher Boessenkool wrote: > Hi! > > Some more nitpicking... > > On Wed, May 18, 2022 at 04:52:26PM +0800, HAO CHEN GUI wrote: >>const double __builtin_vsx_xsmaxdp (double, double); >> -XSMAXDP smaxdf3 {} >> +XSMAXDP

[PATCH-1 v2, rs6000] Replace shift and ior insns with one rotate and mask insn for bswap pattern [PR93453]

Hi, This patch replaces shift and ior insns with one rotate and mask insn for the split patterns which are for DI byte swap on Power6. The test cases shows the optimization. Bootstrapped and tested on ppc64 Linux BE and LE with no regressions. Is this okay for trunk? Any recommendations? Thank

[PATCH v4, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]

Hi, This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000. Tests show that outputs of xs[min/max]dp are consistent with the standard of C99 fmin/max. This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead of smin/max. So the builtins always generate xs[min/max]

Re: [PATCH-1 v2, rs6000] Replace shift and ior insns with one rotate and mask insn for bswap pattern [PR93453]

Hi, On 7/6/2022 下午 11:59, Segher Boessenkool wrote: >> --- /dev/null >> +++ b/gcc/testsuite/gcc.target/powerpc/pr93453-1.c >> @@ -0,0 +1,14 @@ >> +/* { dg-do compile { target lp64 } } */ >> +/* { dg-options "-mdejagnu-cpu=power6 -O2" } */ > It doesn't require -m64, only -mpowerpc64. You can use h

Re: [PATCH v4, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]

Hi, On 8/6/2022 下午 9:24, Segher Boessenkool wrote: > But it regresses the code quality generated with -ffast-math (because > the new unspecs arent't optimised like standard rtl is). This can be > follow-up work of course -- and the best direction is to make fmin/fmax > generic, even! :-) fmin/m

Re: [PATCH v4, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]

On 9/6/2022 下午 11:07, Segher Boessenkool wrote: > Ah, good. Should we then have an assert that there is no fast-math if > we ever get the rtl fmin/fmax stuff? Sure, I will add a condition for it. Thanks a lot. Gui Haochen

[PATCH, rs6000] Use CC for BCD operations [PR100736]

Hi, This patch uses CC instead of CCFP for all BCD operations. Thus, infinite math flag has no impact on BCD operations. To support BCD overflow and invalid coding, ordered and unordered are added into CC mode. With CC, "ge" and "le" are converted to reverse comparison. So the invalid coding need

Re: [PATCH, rs6000] Use CC for BCD operations [PR100736]

Hi, On 16/6/2022 下午 7:24, Segher Boessenkool wrote: > There is no normal way to get at bit 3 of a CR field. We can use some > unspec though, which is total cheating but it does work, and it is > safe, albeit sometimes suboptimal. Thanks so much for your advice. I will use an unspec for setting r

[PATCH v5, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]

Hi, This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000. Tests show that outputs of xs[min/max]dp are consistent with the standard of C99 fmin/max. This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead of smin/max. So the builtins always generate xs[min/max]

Re: [PATCH v5, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]

Hi, On 21/6/2022 上午 7:08, Segher Boessenkool wrote: > && !flag_trapping_math > > and/or whatever else is needed as well here. > I have a question here. fmin/max are folded to MIN/MAX_EXPR when flag_finite_math_only is set. Seems no-trapping-math is no need to fmin/max? Also xs[min|max]dp do rais

[PATCH v2, rs6000] Use CC for BCD operations [PR100736]

Hi, This patch uses CC instead of CCFP for all BCD operations. Thus, infinite math flag has no impact on BCD operations. To support BCD overflow and invalid coding, an UNSPEC is defined to move the bit to a general register. The patterns of condition branch and return with overflow bit are define

[PATCH v6, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]

Hi, This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000. Tests show that outputs of xs[min/max]dp are consistent with the standard of C99 fmin/max. This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead of smin/max. So the builtins always generate xs[min/max]

[PATCH 1/2, rs6000] Add const_anchor for rs6000 [PR33699]

Hi,     This patch adds const_anchor for rs6000. The const_anchor is used in cse pass.     The attachment are the patch diff and change log file.     Bootstrapped and tested on powerpc64le with no regressions. Is this okay for trunk? Any  recommendations? Thanks a lot. * config/rs6

[PATCH 2/2] Bypass BLKmode before try_const_anchors

Hi,     This patch fixes an ICE found by enabling const_anchor for rs6000. The BLKmode constant rtx is sent to try_const_anchors which causes assertion failure in try_const_anchors.     The attachment are the patch diff and change log file.     Bootstrapped and tested on powerpc64le with no

Re: [PATCH 1/2, rs6000] Add const_anchor for rs6000 [PR33699]

15, 2021 at 11:11:32AM +0800, HAO CHEN GUI via Gcc-patches wrote:     This patch adds const_anchor for rs6000. The const_anchor is used in cse pass. 1) This isn't suitable for stage 4. 2) Please add a test case, which shows what it does, that it is useful. 3) Does this work on other OSes

Re: [PATCH 1/2, rs6000] Add const_anchor for rs6000 [PR33699]

David & Segher,    Thanks so much for your explanation. My patch wants to enables the constant anchor on rs6000 as TARGET_ANCHOR_CONST or targetm.anchor_const is undefined. I realized that we have addi and addis instructions. So the range of the offset could be a 32 bit constant.    I put a

Re: [PATCHv2, rs6000] Enable have_cbranchcc4 on rs6000

Hi Segher, 在 2022/11/18 20:18, Segher Boessenkool 写道: > I don't think we should pretend we have any conditional jumps the > machine does not actually have, in cbranchcc4. When would this ever be > useful? cror;beq can be quite expensive, compared to the code it would > replace anyway. > > If so

Re: [PATCHv2, rs6000] Enable have_cbranchcc4 on rs6000

Hi Kewen, 在 2022/11/22 11:11, Kewen.Lin 写道: > Maybe we can adjust prepare_cmp_insn to fail if the constructed cbranchcc4 > pattern doesn't satisfy the predicate of operand 0 rather than to assert. > It's something like: > > if (!insn_operand_matches (icode, 0, test)) > goto fail; > > or only a

Re: [PATCHv2, rs6000] Enable have_cbranchcc4 on rs6000

Hi Segher, Thanks for your comments. 在 2022/11/22 7:49, Segher Boessenkool 写道: > *cbranch_2insn is not a machine insn. It generates a cror and a branch > insn. This makes no sense to have in a cbranchcc: those do a branch > based on an existing cr field, so based on the *output* of that cror. >

[PATCH] Change the behavior of predicate check failure on cbranchcc4 operand0 in prepare_cmp_insn

Hi, I want to enable "have_cbranchcc4" on rs6000. But not all combinations of comparison codes and sub CC modes are benefited to generate cbranchcc4 insns on rs6000. There is an predicate for operand0 of cbranchcc4 to bypass some combinations. It gets assertion failure in prepare_cmp_insn. I thin

[PATCH] Add a new conversion for conditional ternary set into ifcvt [PR106536]

Hi, There is a new insn on my target, which has a nested if_then_else and set -1, 0 and 1 according to a comparison. [(set (match_operand:SI 0 "gpc_reg_operand" "=r") (if_then_else:SI (lt (match_operand:CC 1 "cc_reg_operand" "y") (const_int 0))

Re: [PATCH] Add a new conversion for conditional ternary set into ifcvt [PR106536]

Hi Richard, 在 2022/11/24 4:06, Richard Biener 写道: > Wouldn't we usually either add an optab or try to recog a canonical > RTL form instead of adding a new target hook for things like this? Thanks so much for your comments. Please let me make it clear. Do you mean we should create an optab for "

Ping [PATCH] Change the behavior of predicate check failure on cbranchcc4 operand0 in prepare_cmp_insn

Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607083.html Thanks Gui Haochen 在 2022/11/23 10:54, HAO CHEN GUI 写道: > Hi, > I want to enable "have_cbranchcc4" on rs6000. But not all combinations of > comparison codes and sub CC modes are be

Re: Ping [PATCH] Change the behavior of predicate check failure on cbranchcc4 operand0 in prepare_cmp_insn

Hi Richard, 在 2022/11/29 2:46, Richard Biener 写道: > Anyhow - my question still stands - what's the fallback for the callers > that do not check for failure? How are we sure we're not running into > these when relaxing the requirement that a MODE_CC prepare_cmp_insn > must not fail? I examed the

Re: [PATCH] Add a new conversion for conditional ternary set into ifcvt [PR106536]

Hi Nilsson, 在 2022/12/2 10:49, Hans-Peter Nilsson 写道: > On Wed, 23 Nov 2022, HAO CHEN GUI via Gcc-patches wrote: > >> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi >> index 92bda1a7e14..9823eccbe68 100644 >> --- a/gcc/doc/tm.texi >> +++ b/gcc/doc/tm.texi >&

[PATCH v5, rs6000] Change mode and insn condition for VSX scalar extract/insert instructions

Hi, For scalar extract/insert instructions, exponent field can be stored in a 32-bit register. So this patch changes the mode of exponent field from DI to SI so that these instructions can be generated in a 32-bit environment. Also it removes TARGET_64BIT check for these instructions. The inst

[PATCH v2] Return a NULL rtx when targets don't support cbranchcc4 or predicate check fails in prepare_cmp_insn

Hi, It gets an assertion failure when targers don't support cbranchcc4 or predicate check fails in prepare_cmp_insn. prepare_cmp_insn is a help function to generate compare rtx, so it should not assume that cbranchcc4 is existing or all sub-CC modes are supported on one target. I think it should

Re: [PATCH v2] Return a NULL rtx when targets don't support cbranchcc4 or predicate check fails in prepare_cmp_insn

Hi Richard, 在 2022/12/5 15:31, Richard Biener 写道: > I wonder if you have a testcase you can add showing this change is > worthwhile and > fixes a bug? I want to enable cbranchcc4 on rs6000. But not all sub CCmode is supported on rs6000. So the predicate check(assert) fails and it hits ICE. I draf

[PATCH v3, rs6000] Enable have_cbranchcc4 on rs6000

Hi, This patch enables "have_cbranchcc4" on rs6000 by defining a "cbranchcc4" expander. "have_cbrnachcc4" is a flag in ifcvt.cc to indicate if branch by CC bits is invalid or not. With this flag enabled, some branches can be optimized to conditional moves. The patch relies on the former patch

[PATCH v2] Add a new conversion for conditional ternary set into ifcvt [PR106536]

Hi, This patch adds a new conversion to convert a certain branch to conditional ternary set in ifcvt. The branch commonly has following insns. cond_jump ? pc : label setcc (neg/subreg) label: set a constant cond_jump and setcc use the same CC reg and neg/subreg is optional. The br

Re: [PATCH v3, rs6000] Enable have_cbranchcc4 on rs6000

Hi Kewen, Thanks so much for your review comments. I will fix them. 在 2022/12/7 11:06, Kewen.Lin 写道: > Does this issue which relies on the fix for generic part make bootstrapping > fail? > If no, how many failures it can cause? I'm thinking if we can commit this > firstly, > then in the commi

[PATCH v4, rs6000] Enable have_cbranchcc4 on rs6000

Hi, This patch enables "have_cbranchcc4" on rs6000 by defining a "cbranchcc4" expander. "have_cbrnachcc4" is a flag in ifcvt.cc to indicate if branch by CC bits is invalid or not. With this flag enabled, some branches can be optimized to conditional moves. Compared to last version, the main ch

Re: [PATCH, rs6000] new split pattern for TI to V1TI move [PR103124]

Hi Segher, Thanks for your advice. Please see my comments. On 14/12/2021 上午 6:59, Segher Boessenkool wrote: > Hi! > > On Mon, Dec 13, 2021 at 05:22:06PM -0500, David Edelsohn wrote: >> On Sun, Dec 12, 2021 at 10:00 PM HAO CHEN GUI wrote: >>> --- a/gcc/config/rs6000/vsx

[PATCH, rs6000] new split pattern for TI to V1TI move [PR103124]

Hi, This patch defines a new split pattern for TI to V1TI move. The pattern concatenates two subreg:DI of a TI to a V2DI. With the pattern, the subreg pass can do register split for TI when there is a TI to V1TI move. The patch optimizes one unnecessary "mr" out on P9. The new test case illus

[PATCH, rs6000] Implement mffscrni pattern

Hi, This patch defines a pattern for mffscrni. If the RN is a constant, it can call gen_rs6000_mffscrni directly. The "rs6000-builtin-new.def" defines prototype for builtin arguments. The pattern "rs6000_set_fpscr_rn" is then broken as the mode of its argument is DI while its corresponding bu

[PATCH, rs6000] Implement mffscrni pattern

Hi, I modified the patch according to David and Segher's advice. This patch defines a pattern for mffscrni. If the RN is a constant, it can call gen_rs6000_mffscrni directly. The "rs6000-builtin-new.def" defines prototype for builtin arguments. The pattern "rs6000_set_fpscr_rn" is then broke

[PATCH v3, rs6000] Implement mffscrni pattern

Hi, I modified the patch according to reviewers' advice. This patch defines a pattern for mffscrni. If the RN is a constant, it can call gen_rs6000_mffscrni directly. The "rs6000-builtin-new.def" defines prototype for builtin arguments. The pattern "rs6000_set_fpscr_rn" is then broken as the

[PATCH, rs6000] Fix ICE on expand bcd__ [PR100736]

Hi, This patch fixes the ICE in PR100736. It adds a reverse condition comparison when the condition code can be reversed and finite-math-only is set. Bootstrapped and tested on powerpc64-linux BE and LE with no regressions. Is this okay for trunk? Any recommendations? Thanks a lot. ChangeLo

Re: [PATCH v3, rs6000] Implement mffscrni pattern

Hi Segher, Thanks for your advice. Please see my explanation below. On 22/12/2021 上午 1:05, Segher Boessenkool wrote: > Hi! > > On Tue, Dec 21, 2021 at 04:08:06PM +0800, HAO CHEN GUI wrote: >> This patch defines a pattern for mffscrni. If the RN is a constant,

Ping^1 [PATCH, rs6000] Fix ICE on expand bcd__ [PR100736]

Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587253.html Thanks On 21/12/2021 下午 4:19, HAO CHEN GUI wrote: > Hi, > This patch fixes the ICE in PR100736. It adds a reverse condition > comparison when the > condition code can be reverse

Ping^1 [PATCH, rs6000] new split pattern for TI to V1TI move [PR103124]

Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587051.html Thanks On 17/12/2021 上午 9:55, HAO CHEN GUI wrote: > Hi, >This patch defines a new split pattern for TI to V1TI move. The pattern > concatenates two subreg:DI of > a TI to a V2

Ping^1 [PATCH] Modify combine pattern by a pseudo AND with its nonzero bits [PR93453]

Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586304.html Thanks On 7/12/2021 下午 4:28, HAO CHEN GUI wrote: > Hi, > This patch modifies the combine pattern with a helper - > change_pseudo_and_mask when recog fails. > The helper conve

Re: Ping^1 [PATCH, rs6000] new split pattern for TI to V1TI move [PR103124]

Segher and David, Thanks for your explanation. I got it. The "\m" itself is a constraint escape. Gui Haochen On 11/1/2022 上午 9:12, Segher Boessenkool wrote: > On Mon, Jan 10, 2022 at 06:09:01PM -0500, David Edelsohn wrote: >> On Sun, Jan 9, 2022 at 10:16 PM

[PATCH] Place jump tables in RELRO only when targets require local relocation to be placed in a read-write section

Hi, This patch sets "relocatable" of jump table to true when targets require local relocation to be placed in a read-write section - bit 0 is set in reloc_rw_mask. Jump tables are in local relocation, so they should be placed in RELRO only when both global and local relocation need to be plac

[PATCH, rs6000] Enable absolute jump table by default

Hi, This patch enables absolute jump table by default on rs6000. The relative jump tables are used when it's explicit set by "rs6000_relative_jumptables", or jump tables are placed in text section but global relocation is required. Bootstrapped and tested on powerpc64-linux BE and LE

Re: [PATCH, rs6000] Enable absolute jump table by default

Hi David, On 12/1/2022 下午 10:44, David Edelsohn wrote: > On Wed, Jan 12, 2022 at 7:22 AM HAO CHEN GUI wrote: >> >> Hi, >>This patch enables absolute jump table by default on rs6000. The relative >> jump tables are used when >>it's explicit set by

[PATCH, rs6000] Enable absolute jump table for PPC Linux

Hi, This patch enables absolute jump table on PPC Linux. When PIC is set, the absolute jump tables are placed in RELRO section. Otherwise, they're placed in rodata section. Bootstrapped and tested on powerpc64-linux BE and LE with no regressions. Is this okay for trunk? Any recommendations

Re: [PATCH-1, rs6000] Put constant into pseudo at expand when it needs two insns [PR86106]

Hi Richard, 在 2023/3/16 18:36, Richard Biener 写道: > On Thu, Mar 16, 2023 at 10:04 AM HAO CHEN GUI wrote: >> >> Hi Richard, >> >> 在 2023/3/16 15:57, Richard Biener 写道: >>> So this is one way around the lack of CSE/PRE of constant operands. I'd >>>

Ping [PATCHv3, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]

Hi, Gently ping this: https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613497.html Thanks Gui Haochen 在 2023/3/7 16:55, HAO CHEN GUI 写道: > Hi, > The patch escalates the failure when Hollerith constant to real conversion > fails in native_interpret_expr. It finally reports a

[PATCHv4, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]

Hi, I refined the patch according to reviewer's advice. The main change is to check if buffer_p is set and buffered error exists. Also two regtests are fixed by catching the new error. I sent out the revised one for review due to my limited knowledge on Fortran front end. The patch escalate

Re: [PATCH-1, rs6000] Put constant into pseudo at expand when it needs two insns [PR86106]

Hi Richard, 在 2023/3/16 15:57, Richard Biener 写道: > I'm not sure if careful constraints massaging like adding magic letters to > alternatives with constants to pessimize them for LRA, making them > more expensive than spilling the constant to a register but avoid > secondary reloads with spilling

[PATCH, rs6000] rs6000: correct vector sign extend built-ins on Big Endian [PR108812]

Hi, This patch removes byte reverse operation before vector integer sign extension on Big Endian. These built-ins require to sign extend the rightmost element. So both BE and LE should do the same operation and the byte reversion is no need. This patch fixes it. Now these built-ins have the same

Re: [PATCH] [rs6000] Correct match pattern in pr56605.c

Kewen, The case still fails with trunk. FAIL: gcc.target/powerpc/pr56605.c scan-rtl-dump-times combine "\\(compare:CC \\((?:and|zero_extend):(?:[SD]I) \\((?:sub)?reg:[SD]I" 1 === gcc Summary === # of expected passes1 # of unexpected failures1 With the tr

[PATCHv2, rs6000] rs6000: correct vector sign extend built-ins on Big Endian [PR108812]

Hi, This patch removes byte reverse operation before vector integer sign extension on big endian. These built-ins require to sign extend the element of the input vector that would fall in the least significant portion of the result element. So both BE and LE should do the same operation and the b

[PATCHv3, rs6000] rs6000: correct vector sign extend built-ins on Big Endian [PR108812]

Hi, This patch removes byte reverse operation before vector integer sign extension on big endian. These built-ins require to sign extend the element of the input vector that would fall in the least significant portion of the result element. So both BE and LE should do the same operation and the b

[PATCH, rs6000] xfail float128 comparison test case that fails on powerpc64 [PR108728]

Hi, This patch xfails a float128 comparison test case on powerpc64 that fails due to a longstanding issue with floating-point compares. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684 for more information. The patch passed regression test on Power Linux platforms. Thanks Gui Haochen

Re: [PATCH, rs6000] xfail float128 comparison test case that fails on powerpc64 [PR108728]

Hi Kewen, 在 2023/4/13 16:32, Kewen.Lin 写道: > xfail all powerpc*-*-* can have some XPASSes on those ENVs with > software emulation. Since the related hw insn xscmpuqp is guarded > with TARGET_FLOAT128_HW, could we use the effective target > ppc_float128_hw instead? Thanks for your review comments

[PATCH-2, rs6000] Add ppc_cpu_supports_hw into proc is-effective-target-keyword [PR108728]

Hi, This patch adds ppc_cpu_supports_hw into explicit name checking in proc is-effective-target-keyword. So ppc_cpu_supports_hw can be used as a target selector in test directives. The patch passed regression test on Power Linux platforms. Thanks Gui Haochen ChangeLog rs6000: Add ppc_cpu_sup

[PATCH-1, rs6000] xfail float128 comparison test case that fails on powerpc64 [PR108728]

Hi, This patch xfails a float128 comparison test case on powerpc64 that fails due to a longstanding issue with floating-point compares. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684 for more information. The case is xfailed when instructions of float128 hardware are generated. When

<    1   2   3   4   5