[PATCH, committed] rs6000: Skip debug insns for union [PR105627]

Hi, Bootstrapped and regress-tested on powerpc64-linux-gnu P8 and powerpc64le-linux-gnu P8, P9 and P10. Pushed this as r13-720-g149d04ccbb908b3a251485b43faf204752942b9f. --- As PR105627 exposes, pass analyze_swaps should skip debug insn when doing unionfind_union. One debug insn can use several

Re: [PATCH] rs6000: add support for sanitizers on FreeBSD

Hi Piotr, on 2022/5/23 05:36, Piotr Kubaj wrote: > Ping. > > FreeBSD has already enabled sanitizers in its base system in > https://cgit.freebsd.org/src/commit/?id=f5024381ac16ba43d37a8bd32d54c27f6a6afa66 > The upstream (LLVM) patch was reviewed by a couple of people already. > > Our llvm-devel

[PATCH, committed] testsuite/rs6000: Move pr83660.C to g++.target

Hi, Move pr83660.C to g++.target. As comment #3 of PR83660, renaming it to c isn't one option. This test case isn't tested before, so this brings back the test coverage. Committed as r13-619-g297a69068ddfe2. BR, Kewen - gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr83660.C: Move

[PATCH v3] rs6000: Adjust mov optabs for opaque modes [PR103353]

Hi, As PR103353 shows, we may want to continue to expand a MMA built-in function like a normal function, even if we have already emitted error messages about some missing required conditions. As shown in that PR, without one explicit mov optab on OOmode provided, it would call emit_move_insn recu

[PATCH v3] rs6000: Fix the check of bif argument number [PR104482]

Hi, As PR104482 shown, it's one regression about the handlings when the argument number is more than the one of built-in function prototype. The new bif support only catches the case that the argument number is less than the one of function prototype, but it misses the case that the argument numb

Re: [PATCH v5, rs6000] Add a combine pattern for CA minus one [PR95737]

Hi Haochen, on 2022/5/16 13:22, HAO CHEN GUI wrote: > Hi, >This patch adds a combine pattern for "CA minus one". As CA only has two > values (0 or 1), we could convert following pattern > (sign_extend:DI (plus:SI (reg:SI 98 ca) > (const_int -1 [0x] > t

[PATCH] rs6000: Handle unresolved overloaded builtin [PR105485]

Hi, PR105485 exposes that new builtin function framework doesn't handle unresolved overloaded builtin function well. With new builtin function support, we don't have builtin info for any overloaded rs6000_gen_builtins enum, since they are expected to be resolved to one specific instance. So when

Re: [PATCH V2] powerpc: properly check for feenableexcept() on FreeBSD

on 2022/5/13 04:16, Segher Boessenkool wrote: > Hi Piotr, > > On Tue, May 03, 2022 at 12:21:12PM +0200, pku...@freebsd.org wrote: >> FreeBSD/powerpc* has feenableexcept() defined in fenv.h header. > > Declared, not defined. These are required to be real functions (on all > platforms that have th

Re: [PATCH v4, rs6000] Add a combine pattern for CA minus one [PR95737]

Hi Haochen, on 2022/5/13 09:07, HAO CHEN GUI wrote: > Hi, >This patch adds a combine pattern for "CA minus one". As CA only has two > values (0 or 1), we could convert following pattern > (sign_extend:DI (plus:SI (reg:SI 98 ca) > (const_int -1 [0x] > t

Re: [PATCH V2] powerpc: properly check for feenableexcept() on FreeBSD

Hi Piotr, Thanks for doing this, some comments are inlined. on 2022/5/11 07:32, Piotr Kubaj via Gcc-patches wrote: > Is there anything more required? > > On 22-05-03 12:33:43, Piotr Kubaj wrote: >> Here are gmake check-gfortran results requested by FX. >> >> Before patching: >> =

Re: [PATCH] rs6000: Fix constraint v with rs6000_constraints[RS6000_CONSTRAINT_v]

on 2022/1/27 20:51, Segher Boessenkool wrote: > On Thu, Jan 27, 2022 at 07:24:53PM +0800, Kewen.Lin wrote: >> on 2022/1/27 上午1:57, Segher Boessenkool wrote: >>> I like your original patch better. But for stage 1, sorry. >> >> Thanks Segher! Is it ok to commit it then? Or I'll repost this once >>

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

Hi Segher, on 2022/5/10 20:27, Segher Boessenkool wrote: > Hi guys, > > On Mon, May 09, 2022 at 12:05:51PM +0800, Kewen.Lin wrote: >> on 2022/5/9 09:54, HAO CHEN GUI wrote: >>> This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000. >>> Tests show that outputs of xs[min/max]dp

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

Hi Haochen, Thanks for the patch, some comments are inlined. on 2022/5/9 09:54, 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 standard > of C99 fmin/max. > > Bootstrapped

Re: [PATCH] Skip constant folding for fmin/max when either argument is sNaN [PR105414]

on 2022/5/5 16:09, Richard Biener via Gcc-patches wrote: > On Thu, May 5, 2022 at 10:07 AM HAO CHEN GUI via Gcc-patches > wrote: >> >> Hi, >>This patch skips constant folding for fmin/max when either argument >> is sNaN. According to C standard, >>fmin(sNaN, sNaN）= qNaN, fmin(sNaN, NaN) =

[committed] MAINTAINERS: Add myself as PowerPC port co-maintainer

Hi, Add myself as PowerPC port co-maintainer and to DCO section. Pushed below as r13-127. ChangeLog: * MAINTAINERS: Add myself as PowerPC port co-maintainer and to DCO section. --- MAINTAINERS | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b

Re: [PATCH] testsuite: Add test case for pack/unpack bifs at soft-float [PR105334]

on 2022/4/27 8:46 PM, David Edelsohn wrote: > On Wed, Apr 27, 2022 at 8:22 AM Segher Boessenkool > wrote: >> >> Hi! >> >> Thank you for doing this testcase. >> >> On Wed, Apr 27, 2022 at 06:29:07PM +0800, Kewen.Lin wrote: >>> As discussed in PR105334, this patch is to add the test coverage for >>>

[PATCH] testsuite: Add test case for pack/unpack bifs at soft-float [PR105334]

Hi, As discussed in PR105334, this patch is to add the test coverage for the two recent fixes r12-8091 and r12-8226 from Segher, aix is skipped since it takes soft-float and long-double-128 incompatible. I noticed the referred test case pack02.c skips if powerpc*-*-darwin*, but it's for do-run an

Re: [PATCH] rs6000: Move V2DI vec_neg under power8-vector [PR105271]

on 2022/4/26 11:25 PM, Segher Boessenkool wrote: > On Tue, Apr 26, 2022 at 05:16:18PM +0200, Jakub Jelinek wrote: >> Hi! >> >> On Fri, Apr 15, 2022 at 04:08:15PM +0800, Kewen.Lin via Gcc-patches wrote: >>> As PR105271 shows, __builtin_altivec_neg_v2di requires opt

[PATCH] rs6000: Move V2DI vec_neg under power8-vector [PR105271]

Hi, As PR105271 shows, __builtin_altivec_neg_v2di requires option -mpower8-vector as its pattern expansion relies on subv2di which has guard VECTOR_UNIT_P8_VECTOR_P (V2DImode). This fix is to move the related lines for __builtin_altivec_neg_v2di to the section of stanza power8-vector. Bootstrapp

[PATCH] testsuite: Skip pr105250.c for powerpc and s390 [PR105266]

Hi, The test case pr105250.c is like its related pr105140.c, which suffers the error with message like "{AltiVec,vector} argument passed to unprototyped" on powerpc and s390. So like commits r12-8025 and r12-8039, this fix is to add the dg-skip-if for powerpc*-*-* and s390*-*-*. Tested on powerp

[PATCH v2] rs6000: Fix the check of bif argument number [PR104482]

Hi, As PR104482 shown, it's one regression about the handlings when the argument number is more than the one of built-in function prototype. The new bif support only catches the case that the argument number is less than the one of function prototype, but it misses the case that the argument numb

Re: [PATCH] rs6000: Guard bifs {un, }pack_{longdouble, ibm128} under hard float [PR103623]

on 2022/4/13 3:11 AM, Segher Boessenkool wrote: > On Tue, Apr 12, 2022 at 10:02:06AM +0800, Kewen.Lin wrote: >> on 2022/4/11 11:42 PM, Segher Boessenkool wrote: >>> On Mon, Apr 11, 2022 at 04:29:40PM +0800, Kewen.Lin wrote: Nice, I confirmed this makes ICE gone, I've filed one new PR PR10

Re: [PATCH] rs6000: Guard bifs {un, }pack_{longdouble, ibm128} under hard float [PR103623]

on 2022/4/11 11:42 PM, Segher Boessenkool wrote: > Hi! > > On Mon, Apr 11, 2022 at 04:29:40PM +0800, Kewen.Lin wrote: >> on 2022/4/9 1:31 AM, Segher Boessenkool wrote: >>> On Fri, Apr 08, 2022 at 10:09:44AM +0800, Kewen.Lin wrote: >>> For me it fails during combine: the unspec suddenly doesn't rec

Re: [PATCH] rs6000: Guard bifs {un, }pack_{longdouble, ibm128} under hard float [PR103623]

Hi Segher, on 2022/4/9 1:31 AM, Segher Boessenkool wrote: > On Fri, Apr 08, 2022 at 10:09:44AM +0800, Kewen.Lin wrote: >> As Jakub noted here, we don't have the soft-float support for both m32 and >> m64 >> before, as the bifs are always guarded under hard-float previously. > > But that bug was

[PATCH v3] rs6000: Guard bifs {un, }pack_{longdouble, ibm128} under hard float [PR103623]

Hi, As PR103623 shows, it's a regression failure due to new built-in function framework, previously we guard __builtin_{un,}pack_{longdouble, ibm128} built-in functions under hard float, so they are unavailable with the given configuration. While with new bif infrastructure, it becomes available

[PATCH v2, pushed] rs6000/test: Adjust p9-vec-length-{full, epil}-7.c [PR103196]

t;>>> On Mon, 2022-02-28 at 13:37 +0800, Kewen.Lin via Gcc-patches wrote: >>>>> As PR103196 shows, p9-vec-length-full-7.c needs to be adjusted as the >>>>> complete unrolling can happen on some of its loops. This patch is to >>>>> use pragma &quo

Re: [PATCH v2] rs6000: Guard bifs {un, }pack_{longdouble, ibm128} under hard float [PR103623]

on 2022/4/8 4:04 PM, Jakub Jelinek wrote: > On Fri, Apr 08, 2022 at 03:09:00PM +0800, Kewen.Lin wrote: >> + /* Let's ignore all error messages about built-in function >> + unsupported due to soft-float, since they are not test >> + points here (this case is to check no ICE). */ >> + /* {

Re: [PATCH] rs6000/test: Adjust p9-vec-length-7 sensitive to unroll [PR103196]

Hi Will, on 2022/4/7 10:19 PM, will schmidt wrote: > On Mon, 2022-02-28 at 13:37 +0800, Kewen.Lin via Gcc-patches wrote: >> Hi, >> ... >> - >> PR testsuite/103196 >> >> gcc/testsuite/ChangeLog: >> >> * gcc.target/powerpc/p9-vec-le

Re: [PATCH] rs6000/test: Adjust p9-vec-length-7 sensitive to unroll [PR103196]

Hi! on 2022/4/8 3:29 AM, Segher Boessenkool wrote: > Hi! > > On Thu, Apr 07, 2022 at 09:19:51AM -0500, will schmidt wrote: >> On Mon, 2022-02-28 at 13:37 +0800, Kewen.Lin via Gcc-patches wrote: >>> As PR103196 shows, p9-vec-length-full-7.c needs to be adjusted as the &g

[PATCH v2] rs6000: Guard bifs {un,}pack_{longdouble,ibm128} under hard float [PR103623]

Hi, As PR103623 shows, it's a regression failure due to new built-in function framework, previously we guard __builtin_{un,}pack_{longdouble, ibm128} built-in functions under hard float, so they are unavailable with the given configuration. While with new bif infrastructure, it becomes available

Re: [PATCH] rs6000: Guard bifs {un, }pack_{longdouble, ibm128} under hard float [PR103623]

Hi Segher & Jakub, Thanks for the comments! on 2022/4/7 9:00 PM, Jakub Jelinek wrote: > On Thu, Apr 07, 2022 at 06:09:52AM -0500, Segher Boessenkool wrote: >> Hi! >> >> On Thu, Mar 03, 2022 at 10:11:32AM +0800, Kewen.Lin wrote: >>> As PR103623 shows, it's a regression failure due to new built-in

PING^2 [PATCH] rs6000/test: Adjust p9-vec-length-7 sensitive to unroll [PR103196]

Hi, Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590959.html This patch is to fix one regressed test case, I guess it still can be considered for stage 4. BR, Kewen > on 2022/2/28 1:37 PM, Kewen.Lin via Gcc-patches wrote: >> Hi, >> >> As PR103196

Re: [PATCH] rs6000: Adjust mov optabs for opaque modes [PR103353]

on 2022/4/2 5:52 AM, Peter Bergner wrote: > On 4/1/22 3:50 PM, will schmidt wrote: >> Is there a testcase, new or existing, that illustrates this error path? > > Well, the already existsing test case pr101849.c is where the issue was seen, > but only when compiled by hand outside of the test harne

[PATCH v2] rs6000: Adjust mov optabs for opaque modes [PR103353]

Hi, As PR103353 shows, we may want to continue to expand a MMA built-in function like a normal function, even if we have already emitted error messages about some missing required conditions. As shown in that PR, without one explicit mov optab on OOmode provided, it would call emit_move_insn recu

Re: [PATCH v2] rs6000: Support UN[GL][ET] in rs6000_maybe_emit_maxc_minc [PR105002]

on 2022/4/1 10:49 PM, Segher Boessenkool wrote: > Hi! > > On Fri, Apr 01, 2022 at 02:27:14PM +0800, Kewen.Lin wrote: >> Commit r12-7687 exposed one miss optimization chance in function >> rs6000_maybe_emit_maxc_minc, for now it only considers comparison >> codes GE/GT/LE/LT, but it can support mor

Re: [PATCH] rs6000: Support UN[GL][ET] in rs6000_maybe_emit_maxc_minc [PR105002]

Hi Segher, on 2022/3/27 11:02 PM, Segher Boessenkool wrote: > Hi! > > On Thu, Mar 24, 2022 at 10:00:43AM +0800, Kewen.Lin wrote: >> Commit r12-7687 exposed one miss optimization chance in function >> rs6000_maybe_emit_maxc_minc, for now it only considers comparison >> codes GE/GT/LE/LT, but it ca

[PATCH v2] rs6000: Support UN[GL][ET] in rs6000_maybe_emit_maxc_minc [PR105002]

Hi, Commit r12-7687 exposed one miss optimization chance in function rs6000_maybe_emit_maxc_minc, for now it only considers comparison codes GE/GT/LE/LT, but it can support more variants with codes UNLT/UNLE/UNGT/UNGE by reversing them into the equivalent ones with GE/GT/LE/LT. Bootstrapped and r

[PATCH] rs6000: Support UN[GL][ET] in rs6000_maybe_emit_maxc_minc [PR105002]

Hi, Commit r12-7687 exposed one miss optimization chance in function rs6000_maybe_emit_maxc_minc, for now it only considers comparison codes GE/GT/LE/LT, but it can support more variants with codes UNLT/UNLE/UNGT/UNGE by reversing them into the equivalent ones with GE/GT/LE/LT. Bootstrapped and r

Re: [PATCH] rs6000: Skip overload instances with NULL fntype [PR104967]

on 2022/3/23 8:29 PM, David Edelsohn wrote: > On Wed, Mar 23, 2022 at 5:33 AM Kewen.Lin wrote: >> >> Hi, >> >> As shown in PR104967, for some overload built-in function instance, >> if it requires a date type which isn't defined on the target, its >> fntype would be initialized as NULL. This patc

[PATCH] rs6000: Skip overload instances with NULL fntype [PR104967]

Hi, As shown in PR104967, for some overload built-in function instance, if it requires a date type which isn't defined on the target, its fntype would be initialized as NULL. This patch is to consider this possibility in function find_instance to avoid ICE. Bootstrapped and regtested on powerpc6

PING^1 [PATCH] rs6000: Adjust mov optabs for opaque modes [PR103353]

Hi, Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591150.html BR, Kewen on 2022/3/3 4:38 PM, Kewen.Lin via Gcc-patches wrote: > Hi, > > As PR103353 shows, we may want to continue to expand a MMA built-in > function like a normal function, even if we have alr

PING^1 [PATCH] rs6000: Guard bifs {un, }pack_{longdouble, ibm128} under hard float [PR103623]

Hi, Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591147.html BR, Kewen on 2022/3/3 10:11 AM, Kewen.Lin via Gcc-patches wrote: > Hi, > > As PR103623 shows, it's a regression failure due to new built-in > function framework, previously we guard __b

PING^1 [PATCH] rs6000/test: Adjust p9-vec-length-7 sensitive to unroll [PR103196]

Hi, Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590959.html BR, Kewen on 2022/2/28 1:37 PM, Kewen.Lin via Gcc-patches wrote: > Hi, > > As PR103196 shows, p9-vec-length-full-7.c needs to be adjusted as the > complete unrolling can happen on some of its

PING^1 [PATCH] rs6000: Fix some issues related to Power10 fusion [PR104024]

Hi, Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590692.html BR, Kewen on 2022/2/22 10:47 AM, Kewen.Lin via Gcc-patches wrote: > Hi, > > As PR104024 shows, currently the option -mpower10-fusion isn't guarded > under -mcpu=power10, so compiler can optim

[PATCH] rs6000: Fix the check of bif argument number [PR104482]

Hi, PR104482 is one regression about the handlings on different argument numbers from its prototype of built-in function. Without the patch, the code only catches the case when argument number is more than the one of prototype, but it ignores the possibility that the number of arguments can be mo

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

Hi Haochen, Some minor comments are inlined. on 2022/3/10 2:31 PM, HAO CHEN GUI via Gcc-patches wrote: > Hi, >This patch adds V1TI mode into mode iterator used in vector comparison > expands.With the patch, both built-ins and direct comparison could generate > P10 new V1TI comparison instruct

[PATCH] rs6000: Adjust mov optabs for opaque modes [PR103353]

Hi, As PR103353 shows, we may want to continue to expand a MMA built-in function like a normal function, even if we have already emitted error messages about some missing required conditions. As shown in that PR, without one explicit mov optab on OOmode provided, it would call emit_move_insn recu

[PATCH] rs6000: Guard bifs {un,}pack_{longdouble,ibm128} under hard float [PR103623]

Hi, As PR103623 shows, it's a regression failure due to new built-in function framework, previously we guard __builtin_{un,}pack_{longdouble, ibm128} built-in functions under hard float, so they are unavailable with the given configuration. While with new bif infrastructure, it becomes available

[PATCH] rs6000/test: Adjust p9-vec-length-7 sensitive to unroll [PR103196]

Hi, As PR103196 shows, p9-vec-length-full-7.c needs to be adjusted as the complete unrolling can happen on some of its loops. This patch is to use pragma "GCC unroll 0" to disable all possible loop unrollings. Hope it can help the case not that fragile. There are some other p9-vec-length* cases,

[PATCH] rs6000: Fix some issues related to Power10 fusion [PR104024]

Hi, As PR104024 shows, currently the option -mpower10-fusion isn't guarded under -mcpu=power10, so compiler can optimize some patterns unexpectedly. As the option is undocumented, this patch just simply unmasks it. For some define_insns in fusion.md which have constraint v, they don't have the cor

Re: [PATCH v2, rs6000] Enable absolute jump table for PPC AIX and Linux

on 2022/2/22 上午9:11, HAO CHEN GUI wrote: > > Kewen, > Thanks so much for your advice. > > On 21/2/2022 下午 5:42, Kewen.Lin wrote: >> Hi Haochen, >> >> Some minor comments are inlined. >> >> on 2022/2/16 下午4:42, HAO CHEN GUI via Gcc-patches wrote: >>> Hi, >>>This patch enables absolute jump t

Re: [PATCH v2, rs6000] Enable absolute jump table for PPC AIX and Linux

Hi Haochen, Some minor comments are inlined. on 2022/2/16 下午4:42, HAO CHEN GUI via Gcc-patches wrote: > Hi, >This patch enables absolute jump tables on PPC AIX and Linux. For AIX, the > jump > table is placed in data section. For Linux, it is placed in RELRO section when > relocation is need

Re: [PATCH] PR target/102059 Fix inline of target specific functions

Hi Michael, on 2022/2/9 上午11:27, Michael Meissner via Gcc-patches wrote: > Reset -mpower8-fusion for power9 inlining power8 functions, PR 102059. > > This patch is an attempt to make a much simpler patch to fix PR target/102059 > than the previous patch. > > It just fixes the issue that if a fun

Re: [PATCH v3] rs6000: Fix some issues in rs6000_can_inline_p [PR102059]

Hi Bill, on 2022/2/9 上午4:29, Bill Schmidt wrote: > Hi! > > From some discussion today, I think we want to limit the scope of > this patch to just the power8-fusion flag that's causing trouble for > now, given stage 4. We've talked about making power8-fusion a do- > nothing flag, since it doesn't

Re: [PATCH v3] rs6000: Fix some issues in rs6000_can_inline_p [PR102059]

Hi Segher, Thanks for the comments! on 2022/2/7 下午3:53, Segher Boessenkool wrote: > Hi! > > On Wed, Jan 05, 2022 at 03:34:41PM +0800, Kewen.Lin wrote: >> This patch is to fix the inconsistent behaviors for non-LTO mode >> and LTO mode. As Martin pointed out, currently the function >> rs6000_can

PING^3 [PATCH v3] rs6000: Fix some issues in rs6000_can_inline_p [PR102059]

Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587635.html BR, Kewen >> on 2022/1/5 下午3:34, Kewen.Lin via Gcc-patches wrote: >>> Hi, >>> >>> This patch is to fix the inconsistent behaviors for non-LTO mode >>> and LTO m

Re: [PATCH v2] rs6000: Disable MMA if no VSX support [PR103627]

on 2022/1/28 上午1:17, Segher Boessenkool wrote: > Hi! > > On Thu, Jan 27, 2022 at 07:21:33PM +0800, Kewen.Lin wrote: >> PR target/103627 >> * config/rs6000/rs6000.cc (rs6000_option_override_internal): Disable >> MMA if !TARGET_VSX. >> >> gcc/testsuite/ChangeLog: >> >> PR target/

Re: [PATCH] rs6000: Move the hunk affecting VSX/ALTIVEC ahead [PR103627]

Hi Segher, on 2022/1/27 上午6:42, Segher Boessenkool wrote: > Hi! > > On Thu, Dec 23, 2021 at 10:12:19AM +0800, Kewen.Lin wrote: >> PR target/103627 >> * config/rs6000/rs6000.c (rs6000_option_override_internal): Move the >> hunk affecting VSX and ALTIVEC to the appropriate place. >>

Re: [PATCH] rs6000: Disable MMA if no P9 VECTOR support [PR103627]

Hi Segher, on 2022/1/27 上午6:19, Segher Boessenkool wrote: > Hi! > > On Thu, Dec 23, 2021 at 10:09:27AM +0800, Kewen.Lin wrote: >> As PR103627 shows, there is an unexpected case where !TARGET_VSX >> and TARGET_MMA co-exist. As ISA3.1 claims, SIMD is a requirement >> for MMA. By looking into the

Re: [PATCH] rs6000: Fix constraint v with rs6000_constraints[RS6000_CONSTRAINT_v]

on 2022/1/27 上午1:57, Segher Boessenkool wrote: > Hi! > > On Wed, Jan 26, 2022 at 10:26:45AM +0800, Kewen.Lin wrote: >> on 2022/1/14 上午12:31, David Edelsohn wrote: >> Yeah, but IMHO it still can confuse new comers at first glance. > > Yes, or at least cause to read (well, grep) the whole backend a

[PATCH v2] rs6000: Disable MMA if no VSX support [PR103627]

Hi, As PR103627 shows, there is an unexpected case where !TARGET_VSX and TARGET_MMA co-exist. As ISA3.1 claims, SIMD is a requirement for MMA. By looking into the ICE, I noticed that the current MMA implementation depends on vector pairs load/store which use VSX register, but we don't have a sep

Re: PING^2 [PATCH] rs6000: Fix an assertion in update_target_cost_per_stmt [PR103702]

on 2022/1/26 下午3:28, Richard Biener wrote: > On Wed, Jan 26, 2022 at 3:15 AM Kewen.Lin via Gcc-patches > wrote: >> >> Gentle ping: >> >> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587309.html > > OK. > Thanks Richi! Rebased, re-teste

Re: [PATCH] rs6000: Fix constraint v with rs6000_constraints[RS6000_CONSTRAINT_v]

on 2022/1/14 上午12:31, David Edelsohn wrote: > On Thu, Jan 13, 2022 at 7:28 AM Kewen.Lin wrote: >> >> on 2022/1/13 上午11:56, Kewen.Lin via Gcc-patches wrote: >>> on 2022/1/13 上午11:44, David Edelsohn wrote: >>>> On Wed, Jan 12, 2022 at 10:38 PM Kewen.Lin wrote:

PING^2 [PATCH v3] rs6000: Fix some issues in rs6000_can_inline_p [PR102059]

Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587635.html BR, Kewen > > on 2022/1/5 下午3:34, Kewen.Lin via Gcc-patches wrote: >> Hi, >> >> This patch is to fix the inconsistent behaviors for non-LTO mode >> and LTO mode. As Martin point

PING^2 [PATCH] rs6000: Don't turn off VSX for P9 VECTOR when TARGET_AVOID_XFORM set

Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587449.html BR, Kewen > on 2021/12/29 下午5:36, Kewen.Lin via Gcc-patches wrote: >> Hi, >> >> When TARGET_AVOID_XFORM is set, we turn off VSX. But at least from >> ISA3.0 (Power9), we support DQ fo

PING^2 [PATCH] rs6000: Move the hunk affecting VSX/ALTIVEC ahead [PR103627]

Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587311.html BR, Kewen > on 2021/12/23 上午10:12, Kewen.Lin via Gcc-patches wrote: >> Hi, >> >> There is one hunk checking for functions with target attribute/pragma >> have the same altivec abi as the

PING^2 [PATCH] rs6000: Disable MMA if no P9 VECTOR support [PR103627]

Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587310.html BR, Kewen > on 2021/12/23 上午10:09, Kewen.Lin via Gcc-patches wrote: >> Hi, >> >> As PR103627 shows, there is an unexpected case where !TARGET_VSX >> and TARGET_MMA co-exist. As ISA3.1 cl

PING^2 [PATCH] rs6000: Fix an assertion in update_target_cost_per_stmt [PR103702]

Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587309.html BR, Kewen > on 2021/12/23 上午10:06, Kewen.Lin via Gcc-patches wrote: >> Hi, >> >> This patch is to fix one wrong assertion which is too aggressive. >> Vectorizer can do vec_construct

PING^1 [PATCH v3] rs6000: Fix some issues in rs6000_can_inline_p [PR102059]

Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587635.html BR, Kewen on 2022/1/5 下午3:34, Kewen.Lin via Gcc-patches wrote: > Hi, > > This patch is to fix the inconsistent behaviors for non-LTO mode > and LTO mode. As Martin pointed out, currently

Re: [PATCH] testsuite: Adjust possibly fragile slp-perm-9.c [PR104015]

on 2022/1/19 上午5:34, Segher Boessenkool wrote: > On Tue, Jan 18, 2022 at 11:57:32AM +, Richard Sandiford wrote: >> "Kewen.Lin" writes: PR tree-optimization/104015 * gcc.dg/vect/slp-perm-9.c: Adjust. * gcc.target/powerpc/pr104015-1.c: New test. * gcc.target/power

Re: [PATCH] testsuite: Adjust possibly fragile slp-perm-9.c [PR104015]

on 2022/1/18 上午11:06, Kewen.Lin via Gcc-patches wrote: > Hi, > > As discussed in PR104015, the test case slp-perm-9.c can be > fragile when vectorizer tries to use different vectorisation > strategies. > > As Richard suggested, this patch tries to make the check not > se

[PATCH] testsuite: Adjust possibly fragile slp-perm-9.c [PR104015]

Hi, As discussed in PR104015, the test case slp-perm-9.c can be fragile when vectorizer tries to use different vectorisation strategies. As Richard suggested, this patch tries to make the check not sensitive on the re-trying times by removing the times checking. To still retain the test coverage

Re: [PATCH] rs6000: Use known constant for GET_MODE_NUNITS and similar

on 2022/1/14 下午9:53, David Edelsohn wrote: > On Fri, Jan 14, 2022 at 5:42 AM Kewen.Lin wrote: >> >> on 2022/1/13 下午11:15, David Edelsohn wrote: >>> On Thu, Jan 13, 2022 at 7:40 AM Kewen.Lin wrote: Hi David, on 2022/1/13 上午11:12, David Edelsohn wrote: > On Wed, Jan 12, 2022

[committed] vect: Check partial vector param for supports_partial_vectors [PR104015]

Hi, As described in PR104015, the function partial_vectors_supported_p mainly checks optabs for partial vectors support query, but we still have one parameter param_vect_partial_vector_usage to control the capability. Power9 introduces vector with length instructions (for len_load/len_store) but

Re: [PATCH] rs6000: Use known constant for GET_MODE_NUNITS and similar

on 2022/1/13 下午11:15, David Edelsohn wrote: > On Thu, Jan 13, 2022 at 7:40 AM Kewen.Lin wrote: >> >> Hi David, >> >> on 2022/1/13 上午11:12, David Edelsohn wrote: >>> On Wed, Jan 12, 2022 at 8:56 PM Kewen.Lin wrote: Hi, This patch is to clean up some codes with GET_MODE_UNIT_SIZ

Re: [PATCH] rs6000: Use known constant for GET_MODE_NUNITS and similar

Hi David, on 2022/1/13 上午11:12, David Edelsohn wrote: > On Wed, Jan 12, 2022 at 8:56 PM Kewen.Lin wrote: >> >> Hi, >> >> This patch is to clean up some codes with GET_MODE_UNIT_SIZE or >> GET_MODE_NUNITS, which can use known constant instead. > > I'll let Segher decide, but often the additional

Re: [PATCH] rs6000: Fix constraint v with rs6000_constraints[RS6000_CONSTRAINT_v]

on 2022/1/13 上午11:56, Kewen.Lin via Gcc-patches wrote: > on 2022/1/13 上午11:44, David Edelsohn wrote: >> On Wed, Jan 12, 2022 at 10:38 PM Kewen.Lin wrote: >>> >>> Hi David, >>> >>> on 2022/1/13 上午11:07, David Edelsohn wrote: >>>> On Wed,

Re: [PATCH] rs6000: Fix constraint v with rs6000_constraints[RS6000_CONSTRAINT_v]

on 2022/1/13 上午11:44, David Edelsohn wrote: > On Wed, Jan 12, 2022 at 10:38 PM Kewen.Lin wrote: >> >> Hi David, >> >> on 2022/1/13 上午11:07, David Edelsohn wrote: >>> On Wed, Jan 12, 2022 at 8:56 PM Kewen.Lin wrote: Hi, This patch is to fix register constraint v with rs600

Re: [PATCH] rs6000: Fix constraint v with rs6000_constraints[RS6000_CONSTRAINT_v]

Hi David, on 2022/1/13 上午11:07, David Edelsohn wrote: > On Wed, Jan 12, 2022 at 8:56 PM Kewen.Lin wrote: >> >> Hi, >> >> This patch is to fix register constraint v with >> rs6000_constraints[RS6000_CONSTRAINT_v] instead of ALTIVEC_REGS, >> just like some other existing register constraints with >

PING^1 [PATCH] rs6000: Don't turn off VSX for P9 VECTOR when TARGET_AVOID_XFORM set

Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587449.html on 2021/12/29 下午5:36, Kewen.Lin via Gcc-patches wrote: > Hi, > > When TARGET_AVOID_XFORM is set, we turn off VSX. But at least from > ISA3.0 (Power9), we support DQ form vector load/store. This patch

PING^1 [PATCH] rs6000: Move the hunk affecting VSX/ALTIVEC ahead [PR103627]

Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587311.html on 2021/12/23 上午10:12, Kewen.Lin via Gcc-patches wrote: > Hi, > > There is one hunk checking for functions with target attribute/pragma > have the same altivec abi as the one of main_target_opt, i

PING^1 [PATCH] rs6000: Disable MMA if no P9 VECTOR support [PR103627]

Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587310.html on 2021/12/23 上午10:09, Kewen.Lin via Gcc-patches wrote: > Hi, > > As PR103627 shows, there is an unexpected case where !TARGET_VSX > and TARGET_MMA co-exist. As ISA3.1 claims, SIMD is a requirement &g

PING^1 [PATCH] rs6000: Fix an assertion in update_target_cost_per_stmt [PR103702]

Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587309.html on 2021/12/23 上午10:06, Kewen.Lin via Gcc-patches wrote: > Hi, > > This patch is to fix one wrong assertion which is too aggressive. > Vectorizer can do vec_construct costing for the vector type whic

[PATCH] rs6000: Use known constant for GET_MODE_NUNITS and similar

Hi, This patch is to clean up some codes with GET_MODE_UNIT_SIZE or GET_MODE_NUNITS, which can use known constant instead. Bootstrapped and regtested on powerpc64le-linux-gnu P9 and powerpc64-linux-gnu P8. Is it ok for trunk? BR, Kewen - gcc/ChangeLog: * config/rs6000/altivec.md (a

[PATCH] rs6000: Fix constraint v with rs6000_constraints[RS6000_CONSTRAINT_v]

Hi, This patch is to fix register constraint v with rs6000_constraints[RS6000_CONSTRAINT_v] instead of ALTIVEC_REGS, just like some other existing register constraints with RS6000_CONSTRAINT_*. I happened to see this and hope it's not intentional and just got neglected. Bootstrapped and regtest

Re: [PATCH] rs6000: Remove useless code related to -mno-power10

on 2022/1/11 上午8:26, David Edelsohn wrote: > On Wed, Dec 29, 2021 at 4:37 AM Kewen.Lin wrote: >> >> Hi, >> >> Option -mpower10 was made as "WarnRemoved" since commit r11-2318, >> so -mno-power10 doesn't take effect any more. This patch is to >> remove one line useless code which still respects it

[PATCH v3] rs6000: Fix some issues in rs6000_can_inline_p [PR102059]

Hi, This patch is to fix the inconsistent behaviors for non-LTO mode and LTO mode. As Martin pointed out, currently the function rs6000_can_inline_p simply makes it inlinable if callee_tree is NULL, but it's unexpected, we should use the command line options from target_option_default_node as def

[PATCH] rs6000: Remove useless code related to -mno-power10

Hi, Option -mpower10 was made as "WarnRemoved" since commit r11-2318, so -mno-power10 doesn't take effect any more. This patch is to remove one line useless code which still respects it. Bootstrapped and regtested on powerpc64le-linux-gnu P9 and powerpc64-linux-gnu P8. Is it ok for trunk? BR,

[PATCH] rs6000: Don't turn off VSX for P9 VECTOR when TARGET_AVOID_XFORM set

Hi, When TARGET_AVOID_XFORM is set, we turn off VSX. But at least from ISA3.0 (Power9), we support DQ form vector load/store. This patch is to make it not clear VSX when P9 VECTOR supported, it also checks some flags which P9 VECTOR relies on, otherwise those flags could disable P9 VECTOR later.

[PATCH] rs6000: Move the hunk affecting VSX/ALTIVEC ahead [PR103627]

Hi, There is one hunk checking for functions with target attribute/pragma have the same altivec abi as the one of main_target_opt, it can update both VSX and ALTIVEC flags. Meanwhile, we have some codes to check or warn for some isa flags related to VSX and ALTIVEC, that sit where the mentioned h

[PATCH] rs6000: Disable MMA if no P9 VECTOR support [PR103627]

Hi, As PR103627 shows, there is an unexpected case where !TARGET_VSX and TARGET_MMA co-exist. As ISA3.1 claims, SIMD is a requirement for MMA. By looking into the ICE, I noticed that the current MMA implementation depends on vector pairs load/store, but since we don't have a separated option to

[PATCH] rs6000: Fix an assertion in update_target_cost_per_stmt [PR103702]

Hi, This patch is to fix one wrong assertion which is too aggressive. Vectorizer can do vec_construct costing for the vector type which only has one unit. For the failed case, the passed-in vector type is "vector(1) int", though it doesn't end up with any construction eventually. We have to han

Re: [PATCH] pragma: Update target option node when optimization changes [PR103515]

on 2021/12/9 下午11:21, Martin Liška wrote: > On 12/7/21 03:15, Kewen.Lin wrote: >> Hi, >> >> For a function with optimize pragma, it's possible that the target >> options change as optimization options change.  Now we create one >> optimization option node when parsing pragma optimize, but don't >>

Re: [PATCH] pragma: Update target option node when optimization changes [PR103515]

on 2021/12/9 上午9:43, Jeff Law wrote: > > > On 12/6/2021 7:15 PM, Kewen.Lin via Gcc-patches wrote: >> Hi, >> >> For a function with optimize pragma, it's possible that the target >> options change as optimization options change.  Now we create one >>

Re: [PATCH v2] rs6000: Fix some issues in rs6000_can_inline_p [PR102059]

Hi Segher, on 2021/12/6 下午9:06, Segher Boessenkool wrote: > On Fri, Dec 03, 2021 at 11:46:53AM +0800, Kewen.Lin wrote: This patch is to fix the inconsistent behaviors for non-LTO mode and LTO mode. As Martin pointed out, currently the function rs6000_can_inline_p simply makes it in

[PATCH] pragma: Update target option node when optimization changes [PR103515]

Hi, For a function with optimize pragma, it's possible that the target options change as optimization options change. Now we create one optimization option node when parsing pragma optimize, but don't create target option node for possible target option changes. It makes later processing not det

[PATCH v2] rs6000: Fix some issues in rs6000_can_inline_p [PR102059]

Hi Segher, Thanks for the review! on 2021/11/30 上午12:57, Segher Boessenkool wrote: > Hi! > > On Wed, Sep 01, 2021 at 02:55:51PM +0800, Kewen.Lin wrote: >> This patch is to fix the inconsistent behaviors for non-LTO mode >> and LTO mode. As Martin pointed out, currently the function >> rs6000_ca

Re: [PATCH] rs6000: Fix some issues in rs6000_can_inline_p [PR102059]

Hi Mike, on 2021/12/3 上午8:51, Michael Meissner wrote: > On Mon, Nov 29, 2021 at 10:57:12AM -0600, Segher Boessenkool wrote: >> Why are there OPTION_MASKs for separate P10 fusion types here, as well as >> MASK_P10_FUSION? > > Well going back in time, before we used rs6000_isa_flags, we used the de

Re: [PATCH] Modify combine pattern by a pseudo AND with its nonzero bits [PR93453]

Hi Haochen, on 2021/12/1 下午5:01, HAO CHEN GUI via Gcc-patches wrote: > Hi, > This patch modifies the combine pattern with a helper - > change_pseudo_and_mask when recog fails. > The helper converts a single pseudo to the pseudo AND with a mask if the > outer operator is IOR/XOR/PLUS > and the

Re: [PATCH v2] combine: Tweak the condition of last_set invalidation

Hi Segher, Thanks for the review! on 2021/11/30 上午6:28, Segher Boessenkool wrote: > Hi! > > On Fri, Jun 11, 2021 at 09:16:21PM +0800, Kewen.Lin wrote: +/* Should pick up the lowest luid if the references + are in the same block. */ +if (label_tick == rsp

<    1   2   3   4   5   6   7   8   9   10   >