Re: [PATCH V2] rs6000: add clober and guard for vsx_stxvd2x4_le_const[pr116030]

Hi Jeff, I just noticed this v2 ... on 2024/8/22 14:22, Jiufu Guo wrote: > Hi, > > Previous, vsx_stxvd2x4_le_const_ is introduced for 'split1' pass, > so it is guarded by "can_create_pseudo_p ()". > While, it would be possible to match the pattern of this insn during/after > RA, so this insn cou

Re: [PATCH] rs6000: allow split vsx_stxvd2x4_le_const after RA[pr116030]

Hi, on 2024/8/21 15:23, Jiufu Guo wrote: > Hi, > > Previous, vsx_stxvd2x4_le_const_ is introduced for 'split1' pass, > so it is guarded by "can_create_pseudo_p ()". > While, it would be possible to match the pattern of this insn during/after > RA, so this insn could be updated to make it work for

Re: [PATCH ver 3] rs6000,extend and document built-ins vec_test_lsbb_all_ones and vec_test_lsbb_all_zeros

Hi Carl, on 2024/8/22 23:24, Carl Love wrote: > Gcc maintainers: > > Version 3, fixed a few typos per Kewen's review.  Fixed the expected number > of scan-assembler-times for xvtlsbb and setbc.  Retested on Power 10 LE. > > Version 2, based on discussion additional overloaded instances of the

Re: [PATCH] sched: Don't skip empty block by removing no_real_insns_p [PR108273]

Hi Jeff, on 2024/8/26 06:13, Jeff Law wrote: > > So is this patch still relevant Kewen? Yes, sorry that I forgot to follow up this after stage 1 opens. > > On 12/20/23 2:25 AM, Kewen.Lin wrote: >> Hi, >> >> This patch follows Richi's suggestion "sc

Re: [PATCH] rs6000: Fix PTImode handling in power8 swap optimization pass [PR116415]

Hi Peter, on 2024/8/21 21:14, Peter Bergner wrote: > Our power8 swap optimization pass has some special handling for optimizing > swaps of TImode variables. The test case reported in bugzilla uses a call > to __atomic_compare_exchange, which introduces a variable of PTImode and > that does not g

Re: [PATCH V3 08/10] rs6000: Adjust altivec dot-product backend patterns

Hi Victor, on 2024/8/15 16:44, Victor Do Nascimento wrote: > Following the migration of the dot_prod optab from a direct to a > conversion-type optab, ensure all back-end patterns incorporate the > second machine mode into pattern names. This patch is OK, thanks! BR, Kewen > > gcc/ChangeLog: >

Re: [PATCH ver 2] rs6000,extend and document built-ins vec_test_lsbb_all_ones and vec_test_lsbb_all_zeros

Hi Carl, on 2024/8/9 23:57, Carl Love wrote: > > Gcc maintainers: > > Version 2, based on discussion additional overloaded instances of the > vec_test_lsbb_all_ones and, vec_test_lsbb_all_zeros built-ins has been added.  > The additional instances are for arguments of vector signed char and ve

Re: [PATCH 4/4] rs6000, Add tests and documentation for vector, conversions between integer and float

Hi Carl, on 2024/8/8 01:15, Carl Love wrote: > > >  GCC maintainers: > > The following patch fixes errors in the definition of the > __builtin_vsx_uns_floate_v2di, __builtin_vsx_uns_floato_v2di and > __builtin_vsx_uns_float2_v2di built-ins.  The arguments should be unsigned > but are listed

Re: [PATCH/RFC] LRA: Don't emit move for substituted CONSTATNT_P operand [PR116170]

on 2024/8/13 18:02, Richard Sandiford wrote: > "Kewen.Lin" writes: >> on 2024/8/12 21:02, Richard Sandiford wrote: >>> "Kewen.Lin" writes: >>>> Hi Richard, >>>> >>>> Thanks for the comments! >>>>

Re: [PATCH/RFC] LRA: Don't emit move for substituted CONSTATNT_P operand [PR116170]

on 2024/8/12 21:02, Richard Sandiford wrote: > "Kewen.Lin" writes: >> Hi Richard, >> >> Thanks for the comments! >> >> on 2024/8/12 16:55, Richard Sandiford wrote: >>> "Kewen.Lin" writes: >>>> Hi, >>>> >>

[PATCH 2/2] rs6000: Remove "+" constraint modifier from *vsx_le_perm_store_* insns

Hi, Since *vsx_le_perm_store_* can be split into vector permute and vector store, after reload_completed, we reuse the operand 1 as the destination of vector permute, so we set operand 1 with constraint modifier "+". But since it's taken as pure input in DF and most passes as Richard pointed out

[PATCH 1/2] rs6000: Fix vsx_le_perm_store_* splitters for !reload_completed

Hi, For vsx_le_perm_store_* we have two splitters, one is for !reload_completed and the other is for reload_completed. As Richard pointed out in [1], operand 1 here is a pure input for DF and most passes, but it could be used as the vector rotation (64 bit) destination of itself, so we re-compute

Re: [PATCH/RFC] LRA: Don't emit move for substituted CONSTATNT_P operand [PR116170]

sn_transform (bool check_only_p) > > > > On 8/11/24 21:50, Kewen.Lin wrote: >> diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc >> index 92b343fa99a..f355c6c6168 100644 >> --- a/gcc/lra-constraints.cc >> +++ b/gcc/lra-constraints.cc >> @@ -47

Re: [PATCH/RFC] LRA: Don't emit move for substituted CONSTATNT_P operand [PR116170]

Hi Richard, Thanks for the comments! on 2024/8/12 16:55, Richard Sandiford wrote: > "Kewen.Lin" writes: >> Hi, >> >> Commit r15-2084 exposes one ICE in LRA. Firstly, before >> r15-2084 KFmode has 126 bit precision while V1TImode has 128 >> bit precis

Re: [PATCH] rs6000: Add TARGET_P10_VECTOR for Power10 vector insns [PR116266]

Hi Segher & Peter, Thanks for your comments!! on 2024/8/10 05:43, Segher Boessenkool wrote: > On Fri, Aug 09, 2024 at 03:50:50PM -0500, Peter Bergner wrote: >> On 8/9/24 12:54 PM, Segher Boessenkool wrote: --- a/gcc/config/rs6000/altivec.md +++ b/gcc/config/rs6000/altivec.md @@ -62

Re: [PATCH/RFC] LRA: Don't emit move for substituted CONSTATNT_P operand [PR116170]

Hi Vladimir, on 2024/8/10 01:47, Vladimir Makarov wrote: > > On 8/9/24 05:49, Kewen.Lin wrote: >> Hi, >> >> Commit r15-2084 exposes one ICE in LRA.  Firstly, before >> r15-2084 KFmode has 126 bit precision while V1TImode has 128 >> bit precision, so the su

PING^5 [PATCH] rs6000: Adjust -fpatchable-function-entry* support for dual entry [PR112980]

in will make our life easier. >>> >>> Thanks a lot, >>> >>> Martin >>> >>> >>> On Wed, May 08 2024, Kewen.Lin wrote: >>>> Hi, >>>> >>>> As the discussion in PR112980, although the current >>>

Re: [PATCH 3/4] rs6000, Remove redundant built-in __builtin_vsx_xvcvuxwdp

Hi Carl, on 2024/8/8 01:15, Carl Love wrote: > > GCC maintainers: > > The patch removed the built-in __builtin_vsx_xvcvuxwdp as it is covered by > the overloaded vec_doubleo built-in. > > The patch has been tested on Power 10 LE and BE with no regressions. > > Please let me know if it is acce

Re: [PATCH 2/4] rs6000, remove built-ins __builtin_vsx_vperm_8hi and, __builtin_vsx_vperm_8hi_uns

Hi Carl, on 2024/8/8 01:15, Carl Love wrote: > > GCC maintainers: > > The following patch removes two redundant built-ins __builtin_vsx_vperm_8hi > and __builtin_vsx_vperm_8hi_uns.  The built-ins are covered by the overloaded > vec_perm built-in. > > The patch has been tested on Power 10 LE a

Re: [PATCH 1/4] rs6000, add testcases to the overloaded vec_perm built-in

Hi Carl, on 2024/8/8 01:15, Carl Love wrote: > > GCC maintainers: > > The following patch adds missing test cases for the overloaded vec_perm > built-in.  It also fixes and issue with printing the 128-bit values in the > DEBUG section that was noticed when adding the additional test cases. >

[PATCH] testsuite: Fix fam-in-union-alone-in-struct-2.c with unsigned char [PR116148]

Hi, As PR116148#c7 shows, fam-in-union-alone-in-struct-2.c still fails on hppa which is a BE environment, but by checking more (also confirmed by John in PR116148#c12), it's due to that signedness of plain char on hppa is signed therefore the value of with_fam_3_v.a[7] "8f" get sign extended as "f

[PATCH] rs6000: Add TARGET_P10_VECTOR for Power10 vector insns [PR116266]

Hi, As PR116266 shows, we miss TARGET_P10_VECTOR to guard those Power10 related vector instructions as well as their according built-in functions. This patch is to introduce TARGET_P10_VECTOR which is actually TARGET_POWER10 && TARGET_VSX underlying, it updates many places that should adopt TARGE

[PATCH/RFC] LRA: Don't emit move for substituted CONSTATNT_P operand [PR116170]

Hi, Commit r15-2084 exposes one ICE in LRA. Firstly, before r15-2084 KFmode has 126 bit precision while V1TImode has 128 bit precision, so the subreg (subreg:V1TI (reg:KF 131) 0) is paradoxical_subreg_p, which stops some passes from doing some optimization. After r15-2084, KFmode has the same mo

[PATCH] testsuite, rs6000: Remove all powerpc-*paired* uses

Hi, Similar to r15-710-g458b23bc8b3e2b which removed all uses of powerpc-*-linux*paired*, this patch is to remove the remaining powerpc-*paired* uses which I missed to catch with "*linux*" in search keyword. Bootstrapped and regtested on powerpc64-linux-gnu P8/P9 and powerpc64le-linux-gnu P9 and

Re: [PATCH] rs6000, document built-ins vec_test_lsbb_all_ones and, vec_test_lsbb_all_zeros

on 2024/8/3 05:48, Peter Bergner wrote: > On 7/31/24 10:21 PM, Kewen.Lin wrote: >> on 2024/8/1 01:52, Carl Love wrote: >>> Yes, I noticed that the built-ins were defined as overloaded but only had >>> one definition. Did seem odd to me. >>> >>>> e

Re: [PATCH ver 3] rs6000, Add new overloaded vector shift builtin int128, variants

Hi Carl, on 2024/8/2 03:35, Carl Love wrote: > GCC developers: > > Version 3, updated the testcase dg-do link to dg-do compile.  Moved the new > documentation again.  Retested on Power 10 LE and BE to verify the dg > arguments disable the test on Power10BE but enable the test for Power10LE.  >

Re: [PATCH] testsuite: Adjust fam-in-union-alone-in-struct-2.c to support BE [PR116148]

8. BR, Kewen > > Richard. > >> Qing >> >>> On Jul 31, 2024, at 05:22, Kewen.Lin wrote: >>> >>> Hi, >>> >>> As Andrew pointed out in PR116148, fam-in-union-alone-in-struct-2.c >>> was designed for little-endian, the

Re: [PATCH] rs6000, document built-ins vec_test_lsbb_all_ones and, vec_test_lsbb_all_zeros

on 2024/8/1 01:52, Carl Love wrote: > Kewen: > > On 7/31/24 2:12 AM, Kewen.Lin wrote: >> Hi Carl, >> >> on 2024/7/27 06:56, Carl Love wrote: >>> GCC maintainers: >>> >>> Per a report from a user, the existing vec_test_lsbb_all_ones and, >&

[PATCH] testsuite: Adjust fam-in-union-alone-in-struct-2.c to support BE [PR116148]

Hi, As Andrew pointed out in PR116148, fam-in-union-alone-in-struct-2.c was designed for little-endian, the recent commit r15-2403 made it be tested with running on BE and PR116148 got exposed. This patch is to adjust the expected data for members in with_fam_2_v and with_fam_3_v by considering e

Re: [PATCH] rs6000, document built-ins vec_test_lsbb_all_ones and, vec_test_lsbb_all_zeros

Hi Carl, on 2024/7/27 06:56, Carl Love wrote: > GCC maintainers: > > Per a report from a user, the existing vec_test_lsbb_all_ones and, > vec_test_lsbb_all_zeros built-ins are not documented in the GCC documentation > file. > > The following patch adds missing documentation for the vec_test_ls

Re: [PATCH, rs6000] Add const_vector into any_operand predicate

Hi Haochen, on 2024/7/25 11:34, HAO CHEN GUI wrote: > Hi, > This patch add const_vector into any_operand predicate. From my > understanding, any_operand should include all kinds of operands. > The const_vector should be included. As emit_move_insn doesn't check > the predicate, the const_vector

[PATCH] testsuite, rs6000: Adjust pr78056-[1357].c and remove pr78056-[246].c

Hi, When cleaning up the remaining powerpc_{vsx,altivec}_ok test cases, I found some issues are related to pr78056-*.c. Firstly, the test points of pr78056-[246].c are no longer available since r9-3164 drops many HAVE_AS_* and the expected warning are dropped together, so this patch is to remove t

[PATCH] testsuite, rs6000: Replace powerpc_vsx_ok with powerpc_altivec etc.

Hi, This is a follow up patch for the previous patch adjusting powerpc_vsx_ok with powerpc_vsx, focusing on those test cases which don't really require VSX feature but used powerpc_vsx_ok before, they actually require some other effective target check, like some of them just require ALTIVEC featur

[PATCH] testsuite, rs6000: Fix some run cases with appropriate *_hw

Hi, When cleaning up the remaining powerpc_{vsx,altivec}_ok test cases, I found some dg-do run test cases which should check for the appropriate {p8vector,vmx}_hw check instead. This patch is to adjust them accordingly. Bootstrapped and regtested on powerpc64-linux-gnu P8/P9 and powerpc64le-linu

[PATCH] testsuite, rs6000: Replace powerpc_vsx_ok with powerpc_vsx

Hi, Following up the previous r15-886, this patch to clean up the remaining powerpc_vsx_ok which actually should use powerpc_vsx instead. Bootstrapped and regtested on powerpc64-linux-gnu P8/P9 and powerpc64le-linux-gnu P9 and P10. I'm going to push this next week if no objections. BR, Kewen --

[PATCH] testsuite, rs6000: Remove useless powerpc_{altivec,vsx}_ok

Hi, Checking the existing powerpc_{altivec,vsx}_ok test cases, I found there are some test cases which don't require the checks powerpc_{altivec,vsx} even, some of them already have other effective target check which can cover check powerpc_{altivec,vsx}, or some of them don't actually require VSX

[PATCH] testsuite, rs6000: Make {vmx,vsx,p8vector}_hw check for altivec/vsx feature

Hi, Different from p9vector_hw, vmx_hw/vsx_hw/p8vector_hw checks can still succeed without Altivec/VSX feature support. We have many runnable test cases only checking for these *_hw without extra checking for if Altivec/VSX feature enabled or not. It means they can fail if being tested by explic

Re: [PATCH ver 2] rs6000, Add new overloaded vector shift builtin int128, varients

on 2024/7/29 23:47, Peter Bergner wrote: > On 7/29/24 5:21 AM, Kewen.Lin wrote: >> on 2024/7/27 06:37, Carl Love wrote: >>> --- /dev/null >>> +++ b/gcc/testsuite/gcc.target/powerpc/vec-shift-double-runnable-int128.c >>> @@ -0,0 +1,358 @@ >>> +/* { dg-do

Re: [PATCH] rs6000, add comment to VEC_IC definition

Hi Carl, on 2024/7/27 07:31, Carl Love wrote: > GCC maintainers: > > This patch adds a comment to the VEC_IC definitions to clarify the V1TI > "TARGET_POWER10" mode per the request by Segher in the feedback to patch > "https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658156.html";. > > http

Re: [PATCH ver 2] rs6000, Add new overloaded vector shift builtin int128, varients

Hi Carl, on 2024/7/27 06:37, Carl Love wrote: > GCC developers: > > Version 2, updated rs6000-overload.def to remove adding additonal internal > names and to change XXSLDWI_Q to XXSLDWI_1TI per comments from Kewen.  Move > new documentation statement for the PIVPR built-ins per comments from Ke

Re: [PATCH ver 2] rs6000, remove __builtin_vsx_xvcmp* built-ins

Hi Carl, on 2024/7/24 01:06, Carl Love wrote: > GCC maintainers: > > version 2, Updated patch comments, added missing ChangeLog.  Fixed unintended > line removal. > > The following patch removes the three __builtin_vsx_xvcmp[eq|ge|gt]sp  > builtins as they similar to the overloaded vec_cmp[eq|

Re: [PATCH 1/2] rs6000, Remove __builtin_vec_set_v1ti,, __builtin_vec_set_v2df, __builtin_vec_set_v2di

Hi Carl, on 2024/7/24 01:52, Carl Love wrote: > > GCC maintainers: > > This patch was previously posted.  Per the feedback, it is now the first of > two patches to remove the set built-ins. > > This patch removes the __builtin_vec_set_v1ti, __builtin_vec_set_v2df and > __builtin_vec_set_v2di

Re: [PATCH 2/2] rs6000, remove built-ins __builtin_vsx_set_1ti, __builtin_vsx_set_2df, __builtin_vsx_set_2di

Hi Carl, on 2024/7/24 01:52, Carl Love wrote: > GCC maintainers: > > This patch removes the vsx set built-ins: __builtin_vsx_set_1ti, > __builtin_vsx_set_2df, __builtin_vsx_set_2di.  With the  removal of these > built-ins, the built-in attribute "set", used in the built-in definition > file, i

Re: [PATCH 0/2] rs6000, remove vec and vsx set builtins

Hi Carl, on 2024/7/24 01:32, Carl Love wrote: > GCC maintainers: > > The code generated by using C-code to set a vector element versus using a > built-in has been investigated.  The assembly code generated from the C-code > is as good or better than the assembly code generated for the built-ins

Re: [PATCH] rs6000, Add new overloaded vector shift builtin int128, varients

Hi Carl, Some minor comments are inlined on top of Segher's and Peter's comments. on 2024/7/20 04:04, Carl Love wrote: > GCC developers: > > The following patch adds the int128 varients to the existing overloaded > built-ins vec_sld, vec_sldb, vec_sldw, vec_sll, vec_slo, vec_srdb, vec_srl, > v

Re: [RFC/PATCH] isel: Fold more in gimple_expand_vec_cond_expr with andc/iorc

on 2024/7/24 06:53, Andrew Pinski wrote: > On Mon, Jul 22, 2024 at 7:41 PM Kewen.Lin wrote: >> >> Hi Andrew, >> >> on 2024/7/23 08:09, Andrew Pinski wrote: >>> On Sun, Jun 30, 2024 at 11:17 PM Kewen.Lin wrote: >>>> >>>> Hi, >&

Re: [PATCH] optabs/rs6000: Rename iorc and andc to iorn and andn

Hi Andrew, on 2024/7/24 10:49, Andrew Pinski wrote: > When I was trying to add an scalar version of iorc and andc, the optab that > got matched was for and/ior with the mode of csi and cdi instead of iorc and > andc optabs for si and di modes. Since csi/cdi are the complex integer modes, > we need

Re: [PATCH FYI] [powerpc] [testsuite] reorder dg directives [PR106069]

Hi Alexandre, on 2024/7/23 10:32, Alexandre Oliva wrote: > > The dg-do directive appears after dg-require-effective-target in > g++.target/powerpc/pr106069.C. That doesn't work the way that was > presumably intended. Both of these directives set dg-do-what, but > dg-do does so fully and uncondi

Re: [PATCH] rs6000, Remove __builtin_vec_set_v1ti,, __builtin_vec_set_v2df, __builtin_vec_set_v2di

Hi Carl, on 2024/7/23 01:37, Carl Love wrote: > > Kewen: > > On 7/22/24 2:09 AM, Kewen.Lin wrote: >> Hi Carl, >> >> on 2024/7/18 00:01, Carl Love wrote: >>> GCC maintainers: >>> >>> This patch removes the __builtin_vec_set_v1ti, __built

Re: [RFC/PATCH] isel: Fold more in gimple_expand_vec_cond_expr with andc/iorc

Hi Andrew, on 2024/7/23 08:09, Andrew Pinski wrote: > On Sun, Jun 30, 2024 at 11:17 PM Kewen.Lin wrote: >> >> Hi, >> >> As PR115659 shows, assuming c = x CMP y, there are some >> folding chances for patterns r = c ? 0/z : z/-1: >> - For r = c ?

PING^3 [PATCH] rs6000: Adjust -fpatchable-function-entry* support for dual entry [PR112980]

a lot, > > Martin > > > On Wed, May 08 2024, Kewen.Lin wrote: >> Hi, >> >> As the discussion in PR112980, although the current >> implementation for -fpatchable-function-entry* conforms >> with the documentation (making N NOPs be consecutive), >>

Re: [PATCH-2v5, rs6000] Implement optab_isfinite for SFDF and IEEE128

Hi Haochen, on 2024/7/18 09:45, HAO CHEN GUI wrote: > Hi, > This patch implemented optab_isfinite for SFDF and IEEE128 by > test data class instructions. > > Compared with previous version, the main change is to merge > the patterns of SFDF and IEEE128 into one. > https://gcc.gnu.org/pipermai

Re: [PATCH-3v5, rs6000] Implement optab_isnormal for SFDF and IEEE128

Hi Haochen, on 2024/7/18 09:45, HAO CHEN GUI wrote: > Hi, > This patch implemented optab_isnormal for SFDF and IEEE128 by > test data class instructions. > > Compared with previous version, the main change is to merge > the patterns of SFDF and IEEE128 into one. > https://gcc.gnu.org/pipermai

Re: [PATCH] rs6000, remove __builtin_vsx_xvcmp* built-ins

Hi Carl, on 2024/7/17 23:52, Carl Love wrote: > GCC maintainers: > > The following patch removes the three __builtin_vsx_xvcmp[eq|ge|gt]sp  > builtins as they similar to the overloaded vec_cmp[eq|ge|gt] built-ins.  The > difference is the overloaded built-ins return a vector of boolean or a vec

Re: [PATCH] rs6000, Remove __builtin_vec_set_v1ti,, __builtin_vec_set_v2df, __builtin_vec_set_v2di

Hi Carl, on 2024/7/18 00:01, Carl Love wrote: > GCC maintainers: > > This patch removes the __builtin_vec_set_v1ti, __builtin_vec_set_v2df and > __builtin_vec_set_v2di built-ins.  The users should just use normal C-code to > update the various vector elements.  This change was originally intend

Re: [PATCH V5] report message for operator %a on unaddressible operand

Hi Jeff, on 2024/7/16 13:39, Jiufu Guo wrote: > Hi, > > For PR96866, when printing asm code for modifier "%a", an addressable > operand is required. While the constraint "X" allow any kind of > operand even which is hard to get the address directly. e.g. extern > symbol whose address is in TOC.

Re: [PATCH] testsuite: powerpc: fix dg-do run typo

Hi Sam, on 2024/7/20 07:10, Sam James wrote: > "Kewen.Lin" writes: > >> Hi Sam, > > Hi Kewen, > >> >> on 2024/7/19 11:28, Sam James wrote: >>> 'dg-run' is not a valid dejagnu directive, 'dg-do run' is needed here >>

Re: [PATCH] testsuite: powerpc: fix dg-do run typo

Hi Sam, on 2024/7/19 11:28, Sam James wrote: > 'dg-run' is not a valid dejagnu directive, 'dg-do run' is needed here > for the test to be executed. > > 2024-07-18 Sam James > > PR target/108699 > * gcc.target/powerpc/pr108699.c: Fix 'dg-run' typo. > --- > Kewen, could you check th

Re: [PATCH 1/2] PR 115800: Fix libgfortran build using --with-cpu=power5

Hi Mike, I guess you should CC fort...@gcc.gnu.org as well. on 2024/7/11 01:25, Michael Meissner wrote: > If you build a little endian compiler and select a default CPU of power5 > (i.e. --with-cpu=power5), GCC cannot be built. The reason is that both the > libgfortran and libstdc++-v3 libraries

[PATCH] rs6000: Use standard name uabd for vabsdu insns

Hi, r14-1832 adds recognition pattern, ifn and optab for ABD (ABsolute Difference), we have some vector absolute difference unsigned instructions since ISA 3.0, as the associated test cases shown, they are not exploited well as we don't define it (them) with a standard name. So this patch is to r

Re: [PATCH v2] rs6000: Fix .machine cpu selection w/ altivec [PR97367]

on 2024/7/18 22:14, Peter Bergner wrote: > On 7/18/24 4:14 AM, Kewen.Lin wrote: >>> +/* { dg-final { scan-assembler {\.\mmachine power4\M} } } */ >>> +/* { dg-final { scan-assembler {\.\mmachine altivec\M} } } */ >> >> Nit: Both \m looks useless and can be rem

Re: [PATCH ver 3] rs6000, update effective target for tests builtins-10*.c and, vec_perm-runnable-i128.c

Hi Carl, on 2024/7/18 00:15, Carl Love wrote: > GCC maintainers: > > Version 3, in version 2, the ChangeLog didn't get updated to remove the LP64 > references.  Fixed that and updated the patch description per the feedback > from Peter. > > Version 2, removed the lp64 from the target per discu

Re: [PATCH v2] rs6000: Fix .machine cpu selection w/ altivec [PR97367]

Hi Peter, on 2024/7/13 05:48, Peter Bergner wrote: > René's patch seems to have stalled, so here is an updated version of the > patch with the requested changes to his patch. > > I'll note I have added an additional code change, which is to also emit a > ".machine altivec" if Altivec is enabled.

Re: [PATCHv2, rs6000] Optimize vector construction with two vector doubleword loads [PR103568]

Hi Haochen, on 2024/5/31 11:25, HAO CHEN GUI wrote: > Hi, > This patch optimizes vector construction with two vector doubleword loads. > It generates an optimal insn sequence as "xxlor" has lower latency than > "mtvsrdd" on Power10. > > Compared with previous version, the main change is to us

Re: [PATCH] rs6000: Relax some FLOAT128 expander condition for FLOAT128_IEEE_P [PR105359]

Hi Peter, on 2024/7/17 21:00, Peter Bergner wrote: > On 7/17/24 4:09 AM, Kewen.Lin wrote: >> * config/rs6000/rs6000.md (@extenddf2): Remove condition >> TARGET_LONG_DOUBLE_128 for FLOAT128_IEEE_P modes. > > This all LGTM, except this ChangeLog fragment doesn

[PATCH] rs6000: Relax some FLOAT128 expander condition for FLOAT128_IEEE_P [PR105359]

Hi, As PR105359 shows, we disable some FLOAT128 expanders for 64-bit long double, but in fact IEEE float128 types like __ieee128 are only guarded with TARGET_FLOAT128_TYPE and TARGET_LONG_DOUBLE_128 is only checked when determining if we can reuse long_double_type_node. So this patch is to relax

Re: [PATCH v2] rs6000: Error on CPUs and ABIs that don't support the ROP, protection insns [PR114759]

Hi Peter, on 2024/7/16 06:07, Peter Bergner wrote: > Hi Kewen, > > Here's the updated patch per your review comments, minus your suggestion > to disable the ROP mask which I mentioned isn't needed in my other reply. > > This passed bootstrap and regtesting with no regressions on powerpc64le-linu

Re: [PATCH, rs6000] Remove redundant guard for float128 mode patterns

Hi Haochen, on 2024/7/15 10:14, HAO CHEN GUI wrote: > Hi, > This patch removes FLOAT128_IEEE_P guard when the mode of pattern > is IEEE128 and FLOAT128_IBM_P when the mode of pattern is IBM128. > The mode iterators already do the checking. So they're redundant. > > Bootstrapped and tested on

Re: [PATCHv2, rs6000] Add TARGET_FLOAT128_HW guard for quad-precision insns

Hi Haochen, on 2024/7/15 10:10, HAO CHEN GUI wrote: > Hi, > This patch adds TARGET_FLOAT128_HW into pattern conditions for quad- > precision insns. Some qp patterns are guarded by TARGET_P9_VECTOR > originally, so replace it with "TARGET_FLOAT128_HW". > > For test case float128-cmp2-runnable.

Re: [PATCH] rs6000: Error on CPUs and ABIs that don't support the ROP, protection insns [PR114759]

on 2024/7/16 04:30, Peter Bergner wrote: > On 7/11/24 1:24 AM, Kewen.Lin wrote: >> Sorry for the confusion, I meant for most target options when we emit some >> error >> message meanwhile we also unset it, such as: >> >> if (TARGET_CRYPTO &&a

Re: [REPOST 0/3] Add support for -mcpu=power11

rt > that was posted as suggested by Kewen.Lin. > > The following 3 patches add support for -mcpu=power11 to GCC 15. Assuming > these patches are approved and go into GCC 15, I will need to back port them > to > GCC 14. > > The first patch adds the basic support

[PATCH] rs6000: Change optab for ibm128 and ieee128 conversion

Hi, Currently for 128 bit floating-point ibm128 and ieee128 formats conversion, the corresponding libcalls are: ibm128 -> ieee128 "__trunctfkf2" ieee128 -> ibm128 "__extendkftf2" , and generic code handling (like convert_mode_scalar) also adopts sext_optab for ieee128 -> ibm128 while trunc_opt

[PATCH 2/3 v3] rs6000: Make all 128 bit scalar FP modes have 128 bit precision [PR112993]

Hi, On rs6000, there are three 128 bit scalar floating point modes TFmode, IFmode and KFmode. With some historical reasons, we defines them with different mode precisions, that is KFmode 126, TFmode 127 and IFmode 128. But in fact all of them should have the same mode precision 128, this special

Re: [PATCH, rs6000] Add TARGET_FLOAT128_HW guard for quad-precision insns

Hi Haochen, on 2024/7/11 13:50, HAO CHEN GUI wrote: > Hi, > This patch adds TARGET_FLOAT128_HW into pattern conditions for quad- > precision insns. Also it removes FLOAT128_IEEE_P check from pattern > conditions if the mode of pattern is IEEE128 as the mode iterator - > IEEE128 already checks wi

Re: [PATCH] rs6000: Error on CPUs and ABIs that don't support the ROP, protection insns [PR114759]

on 2024/7/11 11:36, Peter Bergner wrote: > On 7/10/24 1:01 AM, Kewen.Lin wrote: >>> + if (rs6000_rop_protect) >>> +{ >>> + /* Disallow CPU targets we don't support. */ >>> + if (!TARGET_POWER8) >>> + error (

[PATCH] rs6000: Update option set in rs6000_inner_target_options [PR115713]

Hi, When function rs6000_inner_target_options parsing target options, it updates the explicit option set information for rs6000_opt_masks by rs6000_isa_flags_explicit, but it misses to update that information for rs6000_opt_vars, and it can result in some unexpected consequence as the associated t

[PATCH] rs6000: Consider explicitly set options in target option parsing [PR115713]

Hi, In rs6000_inner_target_options, when enabling VSX we enable altivec and disable -mavoid-indexed-addresses implicitly, but it doesn't consider the case that the options altivec and avoid-indexed-addresses can be explicitly disabled. As the test case in PR115713#c1 shows, with target attribute

[PATCH] rs6000: Escalate warning to error for VSX with explicit no-altivec etc.

Hi, As the discussion in PR115688, for now when users specify -mvsx and -mno-altivec explicitly, compiler emits warning rather than error, but considering both options are given explicitly, emitting hard error should be better. So this patch is to escalate some related warning to error when both

Re: [PATCH V4] report message for operator %a on unaddressible operand

Hi Jeff, on 2024/6/5 16:30, Jiufu Guo wrote: > Hi, > > For PR96866, when printing asm code for modifier "%a", an addressable > operand is required. While the constraint "X" allow any kind of > operand even which is hard to get the address directly. e.g. extern > symbol whose address is in TOC. >

Re: [PATCH] rs6000: Error on CPUs and ABIs that don't support the ROP, protection insns [PR114759]

Hi Peter, on 2024/7/10 05:39, Peter Bergner wrote: > Hi Kewen, > > Here is that promised cleanup patch we discussed in the previous patch review. > I'll note this patch is dependent on the previous patch you approved. I have > not pushed that yet (in case you looked) since I'm waiting on Segher

Re: [PATCH-1v5, rs6000] Implement optab_isinf for SFDF and IEEE128

Hi Haochen, on 2024/7/9 15:18, HAO CHEN GUI wrote: > Hi, > This patch implemented optab_isinf for SFDF and IEEE128 by test > data class instructions. > > Compared with previous version, the main changes are: > 1 Define 3 mode attributes which are used for predicate, constraint > and asm print

Re: [PATCH 1/3] expr: Allow same precision modes conversion between {ibm_extended, ieee_quad}_format [PR112993]

Hi Richard, on 2024/7/8 19:14, Richard Sandiford wrote: > "Kewen.Lin" writes:[snip...] >>> >>> This part looks good to me FWIW, but what's the correct behaviour of: >>> >>> if (GET_MODE_PRECISION (from_mode) == GET_MODE_PRECISION (to_mo

[PATCH] rs6000: Remove vcond{,u} expanders

Hi, As PR114189 shows, middle-end will obsolete vcond, vcondu and vcondeq optabs soon. This patch is to remove all vcond{,u} expanders in rs6000 port and adjust the function rs6000_emit_vector_cond_expr which is called by those expanders as static. Bootstrapped and regtested on powerpc64-linux-g

[PATCH] rs6000: Consider explicit VSX when masking off ALTIVEC [PR115688]

Hi, PR115688 exposes an inconsistent state in which we have VSX enabled but ALTIVEC disabled. There is one hunk: if (main_target_opt && !main_target_opt->x_rs6000_altivec_abi) rs6000_isa_flags &= ~((OPTION_MASK_VSX | OPTION_MASK_ALTIVEC) & ~rs6000_isa_flags_explic

Re: [PATCH 1/3] expr: Allow same precision modes conversion between {ibm_extended, ieee_quad}_format [PR112993]

Hi Richard, Thanks for the review comments! on 2024/7/4 23:58, Richard Sandiford wrote: > "Kewen.Lin" writes: >> Hi, >> >> With some historical reasons, rs6000 defines KFmode, TFmode >> and IFmode to have different mode precision, but it causes >> som

[PATCH 3/3] tree: Remove KFmode workaround [PR112993]

Hi, The fix for PR112993 will make KFmode have 128 bit mode precision, we don't need this workaround to fix up the type precision any more, and just go with the mode precision. So this patch is to remove KFmode workaround. Bootstrapped and regtested on x86_64-redhat-linux, powerpc64{,le}-linux-g

[PATCH 2/3 v2] rs6000: Make all 128 bit scalar FP modes have 128 bit precision [PR112993]

Hi, On rs6000, there are three 128 bit scalar floating point modes TFmode, IFmode and KFmode. With some historical reasons, we defines them with different mode precisions, that is KFmode 126, TFmode 127 and IFmode 128. But in fact all of them should have the same mode precision 128, this special

[PATCH 1/3] expr: Allow same precision modes conversion between {ibm_extended, ieee_quad}_format [PR112993]

Hi, With some historical reasons, rs6000 defines KFmode, TFmode and IFmode to have different mode precision, but it causes some issues and needs some workarounds such as r14-6478 for PR112788. So we are going to make all rs6000 128 bit scalar FP modes have 128 bit precision. Be prepared for that

Re: [PATCH 13/13 ver5] rs6000, remove vector set and vector init built-ins.

Hi Carl, on 2024/7/4 07:51, Carl Love wrote: >  GCC maintainers: > > The patch has been updated to remove the customized vec_init built-in code.  > Specfivically the init identifier, the related generated code for the init > built-in attribute bit, function altivec_expand_vec_init_builtin and c

Re: [PATCH 4/13 ver5] rs6000, extend the current vec_{un, }signed{e, o} built-ins

Hi, on 2024/7/4 07:40, Carl Love wrote: > > GCC maintainers: > > I moved the removal of built-ins __builtin_vsx_xvcvdpsxws and > __builtin_vsx_xvcvdpuxws from patch 4 to  patch patch 2. > > I fixed various issues with the ChangeLog wording, spaces and descriptions. > > Fixed the comments in f

Re: [PATCH 2/13 ver5] rs6000, __builtin_vsx_xvcv{sp{sx,u}ws,dpuxds_uns}

Hi, on 2024/7/4 07:33, Carl Love wrote: > GCC maintainers: > > Per the comments on patch 2 from version 4, I have moved the removal of > built-ins __builtin_vsx_xvcvdpsxws and __builtin_vsx_xvcvdpuxws from patch 4 > to this patch. > > Please let me know if this patch is acceptable.  Thanks. >

Re: [PATCH] rs6000, update vec_ld, vec_lde, vec_st and vec_ste, documentation

Hi Carl, on 2024/7/4 01:23, Carl Love wrote: > > On 7/3/24 2:36 AM, Kewen.Lin wrote: >> Hi Carl, >> >> on 2024/6/27 01:05, Carl Love wrote: >>> GCC maintainers: >>> >>> The following patch updates the user documentation for the vec_ld, ve

Re: [PATCH] rs6000: ROP - Emit hashst and hashchk insns on Power8 and later [PR114759]

on 2024/7/3 23:05, Peter Bergner wrote: > On 7/3/24 4:01 AM, Kewen.Lin wrote: >>> - if (TARGET_POWER10 >>> + if (TARGET_POWER8 >>>&& info->calls_p >>>&& DEFAULT_ABI == ABI_ELFv2 >>>&& rs6000_rop_

Re: [PATCH] rs6000, update vec_ld, vec_lde, vec_st and vec_ste, documentation

Hi Carl, on 2024/6/27 01:05, Carl Love wrote: > GCC maintainers: > > The following patch updates the user documentation for the vec_ld, vec_lde, > vec_st and vec_ste built-ins to make it clearer that there are data alignment > requirements for these built-ins. If the data alignment requirement

Re: [PATCH-1v4, rs6000] Implement optab_isinf for SFDF and IEEE128

Hi Haochen, on 2024/6/27 09:41, HAO CHEN GUI wrote: > Hi, > This patch implemented optab_isinf for SFDF and IEEE128 by test > data class instructions. > > Compared with previous version, the main change is to define > and use the constant mask for test data class insns. > https://gcc.gnu.org/

Re: [PATCH] rs6000: ROP - Emit hashst and hashchk insns on Power8 and later [PR114759]

Hi Peter, on 2024/6/20 05:14, Peter Bergner wrote: > We currently only emit the ROP-protect hash* insns for Power10, where the > insns were added to the architecture. We want to emit them for earlier > cpus (where they operate as NOPs), so that if those older binaries are > ever executed on a Pow

PING^1 [PATCH] rs6000: Adjust -fpatchable-function-entry* support for dual entry [PR112980]

Hi, Gentle ping this patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651025.html BR, Kewen on 2024/5/8 13:49, Kewen.Lin wrote: > Hi, > > As the discussion in PR112980, although the current > implementation for -fpatchable-function-entry* conforms > with the document

Re: [PATCH V2] rs6000: load high and low part of 128bit vector independently [PR110040]

Hi Jeevitha, on 2024/6/19 20:39, jeevitha wrote: > Hi All, > > Updated the patch based on review comments. This patch passed bootstrap > and regression testing on powerpc64le-linux with no regressions. > > PR110040 exposes an issue concerning moves from vector registers to GPRs. > There are two

Re: [RFC/PATCH] isel: Fold more in gimple_expand_vec_cond_expr with andc/iorc

Hi! on 2024/7/2 04:28, Segher Boessenkool wrote: > On Mon, Jul 01, 2024 at 04:36:44PM +0200, Richard Biener wrote: >> On Mon, Jul 1, 2024 at 8:17 AM Kewen.Lin wrote: >>> As PR115659 shows, assuming c = x CMP y, there are some >>> folding chances for patterns r = c ? 0/

Re: [PATCH] isel: Fold more in gimple_expand_vec_cond_expr [PR115659]

on 2024/7/1 22:28, Richard Biener wrote: > On Mon, Jul 1, 2024 at 8:16 AM Kewen.Lin wrote: >> >> Hi, >> >> As PR115659 shows, assuming c = x CMP y, there are some >> folding chances for patterns r = c ? -1/z : z/0. >> >> For r = c ? -1 : z, it can be

  1   2   3   4   5   6   7   8   9   10   >