Re: [PATCH 12/13] rs6000, remove __builtin_vsx_xvcmpeqsp built-in

Hi, on 2024/5/24 02:21, Carl Love wrote: > > > On 5/13/24 22:37, Kewen.Lin wrote: >> Hi, >> >> on 2024/4/20 05:18, Carl Love wrote: >>> rs6000, remove __builtin_vsx_xvcmpeqsp built-in >>> >>> The built-in __builtin_vsx_xvcmpeqs

[RFC/PATCH] Replace {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE with new hook

Hi Joseph and Richi, on 2024/5/13 21:18, Joseph Myers wrote: > On Mon, 13 May 2024, Kewen.Lin wrote: > >>> In fact replacing all of X_TYPE_SIZE with a single hook might be worthwhile >>> though this removes the "convenient" defaulting, requiring each target t

Re: [PATCH] missing reuire target has_arch_ppc64 for pr106550.c

Hi Jeff, subject typo: s/reuire/require/ on 2024/5/23 09:11, Jiufu Guo wrote: > Hi, > > Case pr106550.c is testing constant building for 64bit > register. So, this case requires target of has_arch_ppc64. > Nit: Maybe add more comments saying it fails with -m32 without having the expected

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

Hi Carl, on 2024/5/23 08:29, Carl Love wrote: > Kewen: > > On 5/13/24 22:44, Kewen.Lin wrote: >>> perform the same operation as setting a specific element in the vector in >>> C code. For example: >>> >>> src_v4si = __builtin_vec_set_v4si (sr

Re: [PATCH v2] [testsuite] xfail pr79004 on longdouble64; drop long_double_64bit (was: ppc: testsuite: pr79004 needs -mlong-double-128)

Hi, on 2024/5/21 11:04, Alexandre Oliva wrote: > On May 8, 2024, "Kewen.Lin" wrote: > >>>> How about the generic one "longdouble64"? I did a grep and found it has >>>> one >>>> use, I'd expect it can work here. :) >>> &g

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

Hi, on 2024/2/26 13:43, jeevitha wrote: > Hi All, > > The following patch has been bootstrapped and regtested on powerpc64le-linux. > > PR110040 exposes an issue concerning moves from vector registers to GPRs. > There are two moves, one for upper 64 bits and the other for the lower > 64 bits.

Re: [PATCH 6/13] rs6000, add overloaded vec_sel with int128 arguments

Hi Carl, on 2024/5/22 08:13, Carl Love wrote: > Kewen: > > On 5/13/24 19:54, Kewen.Lin wrote: >> Hi, >> >> on 2024/4/20 05:17, Carl Love wrote: >>> rs6000, add overloaded vec_sel with int128 arguments >>> >>> Extend the vec_sel b

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

Hi Carl, on 2024/5/18 04:20, Carl Love wrote: > Kewen: > > I am working thru the patches. I made the changes as requested for this > patch but have a question about > one of your comments. > > On 5/14/24 00:53, Kewen.Lin wrote: >> Hi, >> >> on 2024/

Re: [PATCH] rs6000: Don't clobber return value when eh_return called [PR114846]

Hi, on 2024/5/16 12:08, Andrew Pinski wrote: > > On Thu, May 16, 2024, 4:09 AM Kewen.Lin <mailto:li...@linux.ibm.com>> wrote: > > Hi, > > As the associated test case in PR114846 shows, currently > with eh_return involved some register restoring for EH

[PATCH] rs6000: Don't clobber return value when eh_return called [PR114846]

Hi, As the associated test case in PR114846 shows, currently with eh_return involved some register restoring for EH RETURN DATA in epilogue can clobber the one which holding the return value. Referring to the existing handlings in some other targets, this patch makes eh_return expander call one

Re: [PATCH 1/4] rs6000: Make all 128 bit scalar FP modes have 128 bit precision [PR112993]

Hi Joseph and Richi, Thanks for the suggestions and comments! on 2024/5/10 14:31, Richard Biener wrote: > On Thu, May 9, 2024 at 9:12 PM Joseph Myers wrote: >> >> On Wed, 8 May 2024, Kewen.Lin wrote: >> >>> to widen IFmode to TFmode. To make build_common_

Re: [PATCH 11/13] rs6000, remove __builtin_vsx_xvcmpeqsp_p built-in

Hi, on 2024/4/20 05:18, Carl Love wrote: > rs6000, remove __builtin_vsx_xvcmpeqsp_p built-in > > The built-in __builtin_vsx_xvcmpeqsp_p is a duplicate of the overloaded > __builtin_altivec_vcmpeqfp_p built-in. The built-in is undocumented and > there are no test cases for it. The patch removes

Re: [PATCH 2/13] rs6000, Remove __builtin_vsx_xvcvspsxws built-in

Hi, on 2024/4/20 05:17, Carl Love wrote: > rs6000, Remove __builtin_vsx_xvcvspsxws built-in > > The built-in __builtin_vsx_xvcvspsxws is a duplicate of the vec_signed > built-in that is documented in the PVIPR. The __builtin_vsx_xvcvspsxws > built-in is not documented and there are no test

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

Hi, on 2024/4/20 05:17, Carl Love wrote: > rs6000, extend the current vec_{un,}signed{e,o} built-ins > > The built-ins __builtin_vsx_xvcvspsxds and __builtin_vsx_xvcvspuxds > convert a vector of floats to signed/unsigned long long ints. Extend the > existing vec_{un,}signed{e,o} built-ins to

Re: [PATCH 3/13] rs6000, fix error in unsigned vector float to unsigned int built-in definitions

Hi, on 2024/4/20 05:17, Carl Love wrote: > rs6000, fix error in unsigned vector float to unsigned int built-in > definitions > > The built-ins __builtin_vsx_vunsigned_v2df and__builtin_vsx_vunsigned_v4sf > are supposed to take a vector of floats and return a vector of unsigned > long long

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

Hi, on 2024/4/20 05:18, Carl Love wrote: > rs6000, remove vector set and vector init built-ins. > > The vector init built-ins: > > __builtin_vec_init_v16qi, __builtin_vec_init_v8hi, > __builtin_vec_init_v4si, __builtin_vec_init_v4sf, > __builtin_vec_init_v2di, __builtin_vec_init_v2df, >

Re: [PATCH 12/13] rs6000, remove __builtin_vsx_xvcmpeqsp built-in

Hi, on 2024/4/20 05:18, Carl Love wrote: > rs6000, remove __builtin_vsx_xvcmpeqsp built-in > > The built-in __builtin_vsx_xvcmpeqsp is a duplicate of the overloaded > vec_cmpeq built-in. The built-in is undocumented. The built-in and > the test cases are removed. > > gcc/ChangeLog: > *

Re: [PATCH 10/13] rs6000, extend vec_xxpermdi built-in for __int128 args

Hi, on 2024/4/20 05:18, Carl Love wrote: > rs6000, extend vec_xxpermdi built-in for __int128 args > > Add a new overloaded instance for vec_xxpermdi > >__int128 vec_xxpermdi (__int128, __int128, const int); > > Update the documentation to include a reference to the new built-in > instance.

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

Hi, on 2024/5/14 11:00, Jiufu Guo wrote: > Hi, > > Thanks a lot for your helpful review! > > "Kewen.Lin" writes: > >> Hi, >> >> on 2024/5/13 10:57, Jiufu Guo wrote: >>> Hi, >>> >>> For PR96866, when gcc print asm code f

Re: [PATCH 9/13] rs6000, remove __builtin_vsx_xvnegdp and __builtin_vsx_xvnegsp built-ins

Hi, on 2024/4/20 05:18, Carl Love wrote: > rs6000, remove __builtin_vsx_xvnegdp and __builtin_vsx_xvnegsp built-ins > > The undocumented __builtin_vsx_xvnegdp and __builtin_vsx_xvnegsp are > redundant. The overloaded vec_neg built-in provides the same > functionality. The two buit-ins are not

Re: [PATCH 8/13] rs6000, remove __builtin_vsx_vperm_* built-ins

Hi, on 2024/4/20 05:18, Carl Love wrote: > rs6000, remove __builtin_vsx_vperm_* built-ins > > The undocumented built-ins: > __builtin_vsx_vperm_16qi_uns, > __builtin_vsx_vperm_1ti, > __builtin_vsx_vperm_1ti_uns, > __builtin_vsx_vperm_2df, > __builtin_vsx_vperm_2di, >

Re: [PATCH 7/13] rs6000, remove the vec_xxsel built-ins, they are duplicates

Hi, on 2024/4/20 05:18, Carl Love wrote: > rs6000, remove the vec_xxsel built-ins, they are duplicates > > The following undocumented built-ins are covered by the existing overloaded > vec_sel built-in definitions. > > const vsc __builtin_vsx_xxsel_16qi (vsc, vsc, vsc); > same as vsc

Re: [PATCH 6/13] rs6000, add overloaded vec_sel with int128 arguments

Hi, on 2024/4/20 05:17, Carl Love wrote: > rs6000, add overloaded vec_sel with int128 arguments > > Extend the vec_sel built-in to take three signed/unsigned int128 arguments > and return a signed/unsigned int128 result. > > Extending the vec_sel built-in makes the existing buit-ins >

Re: [PATCH 5/13] rs6000, remove duplicated built-ins of vecmergl and vec_mergeh

Hi, on 2024/4/20 05:17, Carl Love wrote: > rs6000, remove duplicated built-ins of vecmergl and vec_mergeh > > The following undocumented built-ins are same as existing documented > overloaded builtins. > > const vf __builtin_vsx_xxmrghw (vf, vf); > same as vf __builtin_vec_mergeh (vf, vf);

Re: [PATCH] rs6000: Enable overlapped by-pieces operations

Hi, on 2024/5/9 15:35, HAO CHEN GUI wrote: > Hi Kewen, > Thanks for your comments. > > 在 2024/5/9 13:44, Kewen.Lin 写道: >> Hi, >> >> on 2024/5/8 14:47, HAO CHEN GUI wrote: >>> Hi, >>> This patch enables overlapped by-piece operations. On r

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

Hi, on 2024/5/13 10:57, Jiufu Guo wrote: > Hi, > > For PR96866, when gcc print asm code for modifier "%a" which requires > an address operand, while the operand is with the constraint "X" which > allow non-address form. An error message would be reported to indicate > the invalid asm operands.

Re: [PATCH 1/13] rs6000, Remove __builtin_vsx_cmple* builtins

Hi, on 2024/4/20 05:16, Carl Love wrote: > > rs6000, Remove __builtin_vsx_cmple* builtins > > The built-ins __builtin_vsx_cmple_u16qi, __builtin_vsx_cmple_u2di, > __builtin_vsx_cmple_u4si and __builtin_vsx_cmple_u8hi should take > unsigned arguments and return an unsigned result. The current

Re: [PATCHv2] rs6000: Enable overlapped by-pieces operations

on 2024/5/10 17:29, HAO CHEN GUI wrote: > Hi, > This patch enables overlapped by-piece operations. On rs6000, default > move/set/clear ratio is 2. So the overlap is only enabled with compare > by-pieces. > > Compared to previous version, the change is to remove power8 > requirement from test

Re: [PATCH] rs6000: Enable overlapped by-pieces operations

Hi, on 2024/5/8 14:47, HAO CHEN GUI wrote: > Hi, > This patch enables overlapped by-piece operations. On rs6000, default > move/set/clear ratio is 2. So the overlap is only enabled with compare > by-pieces. Thanks for enabling this, did you evaluate if it can help some benchmark? > >

Re: [PATCH 2/4] fortran: Teach get_real_kind_from_node for Power 128 fp modes [PR112993]g

Hi, on 2024/5/9 06:01, Steve Kargl wrote: > On Wed, May 08, 2024 at 01:27:53PM +0800, Kewen.Lin wrote: >> >> Previously effective target fortran_real_c_float128 never >> passes on Power regardless of the default 128 long double >> is ibmlongdouble or ieeelongdouble.

Re: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128

on 2024/4/30 07:11, Alexandre Oliva wrote: > On Apr 29, 2024, "Kewen.Lin" wrote: > >> Thanks for catching this and sorry >> that I didn't check it before suggesting it, I think we can aggressively >> drop this effective target instead to avoid any possibl

Re: [PATCH] rs6000: Adjust -fpatchable-function-entry* support for dual entry [PR112980]

Hi Richi, >> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi >> index c584664e168..58e48f7dc55 100644 >> --- a/gcc/doc/invoke.texi >> +++ b/gcc/doc/invoke.texi >> @@ -18363,11 +18363,11 @@ If @code{N=0}, no pad location is recorded. >> The NOP instructions are inserted at---and maybe

[PATCH] testsuite, rs6000: Remove powerpcspe test cases and checks

Hi, Since r9-4728 the powerpcspe support had been removed, this follow-up patch is to remove the remaining pieces in testsuite. Regtested on powerpc64-linux-gnu P8/P9 and powerpc64le-linux-gnu P9 and P10. I'm going to push this soon if no objections. BR, Kewen - gcc/testsuite/ChangeLog:

[PATCH] testsuite, rs6000: Remove powerpc_popcntb_ok

Hi, There are three uses of effective target powerpc_popcntb_ok, they are all for compiling, but powerpc_popcntb_ok checks for executable generation, which is too heavy. This patch is to remove powerpc_popcntb_ok and adjust its three uses accordingly. Regtested on powerpc64-linux-gnu P8/P9 and

[PATCH 1/2] testsuite, rs6000: Make powerpc_vsx consider current_compiler_flags [PR114842]

Hi, As noted in PR114842, most of the test cases which require effective target check powerpc_vsx_ok actually care about if VSX feature is enabled, and they should adopt effective target powerpc_vsx instead. By considering we already have a number of test cases having explicit -mvsx in

[PATCH] testsuite, rs6000: Remove effective target powerpc_405_nocache

Hi, With the introduction of -mdejagnu-cpu=, when the test case is specifying -mdejagnu-cpu=405, it would override the other possibly given -mcpu=, so it would compile for PowerPC 405 for sure. This patch is to remove the effective target powerpc_405_nocache and update all its uses. Regtested

[PATCH] libgcc, rs6000: Remove powerpcspe related code

Hi, Since r9-4728 the powerpcspe support had been removed, this follow-up patch is to remove the remaining pieces in libgcc. Bootstrapped and regtested on powerpc64-linux-gnu P8/P9 and powerpc64le-linux-gnu P9 and P10. I'm going to push this soon if no objections. BR, Kewen -

[PATCH] rs6000: Add assert !TARGET_VSX if !TARGET_ALTIVEC and strip a useless check

Hi, In function rs6000_option_override_internal, we have the checks and adjustments like: if (TARGET_P8_VECTOR && !TARGET_ALTIVEC) rs6000_isa_flags &= ~OPTION_MASK_P8_VECTOR; if (TARGET_P8_VECTOR && !TARGET_VSX) rs6000_isa_flags &= ~OPTION_MASK_P8_VECTOR; But in fact some previous

[PATCH] testsuite, rs6000: Remove all linux*paired* checks and cases

Hi, Since r9-115-g559289370f76bf the support of paired single had been dropped, but we still have some test checks and cases for that, this patch is to get rid of them. Regtested on powerpc64-linux-gnu P8/P9 and powerpc64le-linux-gnu P9 and P10. I'm going to push this soon if no objections.

[PATCH] testsuite, rs6000: Remove some checks with aix[456]

Hi, Since r12-75-g0745b6fa66c69c aix6 support had been dropped, so we don't need to check for aix[456].* when testing, this patch is to remove such checks. Regtested on powerpc64-linux-gnu P8/P9 and powerpc64le-linux-gnu P9 and P10. I'm going to push this soon if no objections. BR, Kewen -

[PATCH] testsuite: Fix typo in torture/vector-{1,2}.c

Hi, When making some clean up patches, I happened to find test cases vector-{1,2}.c are having typo "powerpc64--*-*" in target selector, which should be powerpc64-*-*. The reason why we didn't catch before is that all our testing machines support VMX insns, so it passes always. But it would

[PATCH] rs6000: Drop useless vector_{load,store}_ defines

Hi, When I was working on a patch to get rid of TFmode, I noticed that define_expands vector_load_ and vector_store_ are useless. This patch is to clean up both. Bootstrapped and regtested on powerpc64-linux-gnu P8/P9 and powerpc64le-linux-gnu P9 and P10. I'm going to push this soon if no

[PATCH] rs6000: Remove useless entries in rreg

Hi, When I was working on a trial patch to get rid of TFmode, I noticed that mode attribute rreg only gets used for mode iterator SFDF, it means that only SF and DF key-value pairs are useful, the other are useless, so this patch is to clean up them. Bootstrapped and regtested on

[PATCH] rs6000: Remove useless operands[3]

Hi, As shown, three uses of operands[3] are totally useless, so this patch is to remove them to avoid any confusion. Bootstrapped and regtested on powerpc64-linux-gnu P8/P9 and powerpc64le-linux-gnu P9 and P10. I'm going to push this soon if no objections. BR, Kewen - gcc/ChangeLog:

[PATCH] rs6000: Clean up TF and TD check with FLOAT128_2REG_P

Hi, Commit r6-2116-g2c83faf86827bf did some clean up on TFmode and TFmode check with FLOAT128_2REG_P, but it missed to update an assertion, this patch is to make it align. btw, it's noticed when I'm making a patch to get rid of TFmode. Bootstrapped and regtested on powerpc64-linux-gnu P8/P9 and

[PATCH] rs6000: Fix ICE on IEEE128 long double without vsx [PR114402]

Hi, As PR114402 shows, we supports IEEE128 format long double even if there is no vsx support, but there is an ICE about cbranch as the test case shows. For now, we only supports compare:CCFP pattern for IEEE128 fp if TARGET_FLOAT128_HW, so in function rs6000_generate_compare we have a check

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

Hi, As the discussion in PR112980, although the current implementation for -fpatchable-function-entry* conforms with the documentation (making N NOPs be consecutive), it's inefficient for both kernel and userspace livepatching (see comments in PR for the details). So this patch is to change the

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

Hi, The fix for PR112993 makes KFmode have 128 bit mode precision, we don't need this workaround to fix up the type precision any more, and just go with mode precision. So this patch is to remove KFmode workaround. Bootstrapped and regress-tested on: - powerpc64-linux-gnu P8/P9 (with ibm128

[PATCH 3/4] ranger: Revert the workaround introduced in PR112788 [PR112993]

Hi, This reverts commit r14-6478-gfda8e2f8292a90 "range: Workaround different type precision between _Float128 and long double [PR112788]" as the fixes for PR112993 make all 128 bits scalar floating point have the same 128 bit precision, this workaround isn't needed any more. Bootstrapped and

[PATCH 2/4] fortran: Teach get_real_kind_from_node for Power 128 fp modes [PR112993]

Hi, Previously effective target fortran_real_c_float128 never passes on Power regardless of the default 128 long double is ibmlongdouble or ieeelongdouble. It's due to that TF mode is always used for kind 16 real, which has precision 127, while the node float128_type_node for c_float128 has 128

[PATCH 1/4] 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

Re: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128

on 2024/4/29 15:20, Alexandre Oliva wrote: > On Apr 28, 2024, "Kewen.Lin" wrote: > >> OK, from this perspective IMHO it seems more clear to adopt xfail >> with effective target long_double_64bit? > > That's effective target is quite broken, alas. I do

Re: [PATCH] adjust vectorization expectations for ppc costmodel 76b

on 2024/4/29 14:28, Alexandre Oliva wrote: > On Apr 28, 2024, "Kewen.Lin" wrote: > >> Nit: Maybe add a prefix "testsuite: ". > > ACK > >>> >>> From: Kewen Lin > >> Thanks, you can just drop this. :) > > I'

Re: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128

Hi, on 2024/4/28 16:20, Alexandre Oliva wrote: > On Apr 23, 2024, "Kewen.Lin" wrote: > >> This patch seemed to miss to CC gcc-patches list. :) > > Oops, sorry, thanks for catching that. > > Here it is. FTR, you've already responded suggesting an apparent &g

Re: [PATCH] adjust vectorization expectations for ppc costmodel 76b

Hi, on 2024/4/28 16:14, Alexandre Oliva wrote: > On Apr 24, 2024, "Kewen.Lin" wrote: > >> For !has_arch_pwr7 case, it still adopts peeling but as the comment (one >> line above) >> shows the original intention of this case is to expect not profitable for

Re: [PATCH] adjust vectorization expectations for ppc costmodel 76b

Hi, on 2024/4/22 17:28, Alexandre Oliva wrote: > Ping? > https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566525.html > > > This test expects vectorization at power8+ because strict alignment is > not required for vectors. For power7, vectorization is not to take > place because it's not

Re: [PATCH v2] [testsuite] require sqrt_insn effective target where needed

Hi, on 2024/4/22 17:56, Alexandre Oliva wrote: > This patch takes feedback received for 3 earlier patches, and adopts a > simpler approach to skip the still-failing tests, that I believe to be > in line with ppc maintainers' expressed preferences. >

Re: [PATCH v2] xfail fetestexcept test - ppc always uses fcmpu

Hi, on 2024/4/22 18:00, Alexandre Oliva wrote: > On Mar 10, 2021, Joseph Myers wrote: > >> On Wed, 10 Mar 2021, Alexandre Oliva wrote: >>> operand exception for quiet NaN. I couldn't find any evidence that >>> the rs6000 backend ever outputs fcmpo. Therefore, I'm adding the same >>> execution

Re: [PATCH] ppc: testsuite: vec-mul requires vsx runtime

on 2024/4/22 17:35, Alexandre Oliva wrote: > Ping? > https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593947.html > > > vec-mul is an execution test, but it only requires a powerpc_vsx_ok > effective target, which is enough only for compile tests. In order to > To check for runtime and

Re: [PATCH] Request check for hw support in ppc run tests with -maltivec/-mvsx

on 2024/4/22 17:31, Alexandre Oliva wrote: > > From: Olivier Hainque > > Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also tested with > gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install? OK, thanks! BR, Kewen > > for gcc/testsuite/ChangeLog > > *

Re: [PATCH] disable ldist for test, to restore vectorizing-candidate loop

on 2024/4/22 17:27, Alexandre Oliva wrote: > Ping? > https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566524.html > > The loop we're supposed to try to vectorize in > gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c is turned into a memset > before the vectorizer runs. > > Various other tests

Re: [PATCH] [testsuite] [ppc64] expect error on vxworks too

on 2024/4/22 17:23, Alexandre Oliva wrote: > > These ppc lp64 tests check for errors or warnings on -mno-powerpc64. > On powerpc64-*-vxworks* we get the same errors as on most other > covered platforms, but the tests did not mark them as expected for > this target. On powerpc-*-vxworks*, the

Re: [PATCH, rs6000] Use bcdsub. instead of bcdadd. for bcd invalid number checking

Hi, on 2024/4/18 10:01, HAO CHEN GUI wrote: > Hi, > This patch replace bcdadd. with bcdsub. for bcd invalid number checking. > bcdadd on two same numbers might cause overflow which also set > overflow/invalid bit so that we can't distinguish it's invalid or overflow. > The bcdsub doesn't have

[PATCH] testsuite, rs6000: Fix builtins-6-p9-runnable.c for BE [PR114744]

Hi, Test case builtins-6-p9-runnable.c doesn't work well on BE due to two problems: - When applying vec_xl_len onto data_128 and data_u128 with length 8, it expects to load 128[01] from the memory, but unfortunately assigning 128[01] to a {vector} {u,}int128 type variable,

Re: [PATCH V3] rs6000: Don't ICE when compiling the __builtin_vsx_splat_2di built-in [PR113950]

Hi, on 2024/4/17 17:05, jeevitha wrote: > Hi, > > On 18/03/24 7:00 am, Kewen.Lin wrote: > >>> The bogus vsx_splat_ code goes all the way back to GCC 8, so we >>> should backport this fix. Segher and Ke Wen, can we get an approval >>> to backport this t

Re: [PATCH, rs6000] Fix test case bcd4.c

Hi, on 2024/4/17 13:12, HAO CHEN GUI wrote: > Hi, > This patch fixes loss of return statement in maxbcd of bcd-4.c. Without > return statement, it returns an invalid bcd number and make the test > noneffective. The patch also enables test to run on Power9 and Big Endian, > as all bcd

Re: [PATCH] rs6000: Add OPTION_MASK_POWER8 [PR101865]

Hi, on 2024/4/12 06:15, Peter Bergner wrote: > FYI: This patch is an update to Will Schmidt's patches to fix PR101865: > > https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601825.html > https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601823.html > > ...taking into

Re: [PATCH] testsuite: Adjust pr113359-2_*.c with unsigned long long [PR114662]

on 2024/4/10 15:11, Richard Biener wrote: > On Wed, Apr 10, 2024 at 8:24 AM Kewen.Lin wrote: >> >> Hi, >> >> pr113359-2_*.c define a struct having unsigned long type >> members ay and az which have 4 bytes size at -m32, while >> the related consta

[PATCH] testsuite: Adjust pr113359-2_*.c with unsigned long long [PR114662]

Hi, pr113359-2_*.c define a struct having unsigned long type members ay and az which have 4 bytes size at -m32, while the related constants CL1 and CL2 used for equality check are always 8 bytes, it makes compiler consider the below 69 if (a.ay != CL1) 70 __builtin_abort (); always to

Re: [PATCH] rs6000: Replace OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR [PR101865]

on 2024/4/9 11:20, Peter Bergner wrote: > On 4/8/24 9:37 PM, Kewen.Lin wrote: >> on 2024/4/8 21:21, Peter Bergner wrote: >> I prefer to remove it completely, that is: >> >>> -mdirect-move >>> -Target Undocumented Mask(DIRECT_MOVE) Var(rs6000_isa_flags) War

Re: [PATCH] rs6000: Replace OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR [PR101865]

Hi Peter, on 2024/4/8 21:21, Peter Bergner wrote: > On 4/8/24 3:55 AM, Kewen.Lin wrote: >> on 2024/4/6 06:28, Peter Bergner wrote: >>> +mno-direct-move >>> +Target Undocumented WarnRemoved >>> + >>> mdirect-move >>> -Target Undocument

Re: [PATCH] testsuite: Add profile_update_atomic check to gcov-20.c [PR114614]

on 2024/4/8 18:47, Richard Biener wrote: > On Mon, Apr 8, 2024 at 11:23 AM Kewen.Lin wrote: >> >> Hi, >> >> As PR114614 shows, the newly added test case gcov-20.c by >> commit r14-9789-g08a52331803f66 failed on targets which do >> not support atomic p

Re: [PATCH] rs6000: Fix wrong align passed to build_aligned_type [PR88309]

on 2024/4/8 18:47, Richard Biener wrote: > On Mon, Apr 8, 2024 at 11:22 AM Kewen.Lin wrote: >> >> Hi, >> >> As the comments in PR88309 show, there are two oversights >> in rs6000_gimple_fold_builtin that pass align in bytes to >> build_aligned_type but w

[PATCH] rs6000: Fix wrong align passed to build_aligned_type [PR88309]

Hi, As the comments in PR88309 show, there are two oversights in rs6000_gimple_fold_builtin that pass align in bytes to build_aligned_type but which actually requires align in bits, it causes unexpected ICE or hanging in function is_miss_rate_acceptable due to zero align_unit value. This patch

[PATCH] testsuite: Add profile_update_atomic check to gcov-20.c [PR114614]

Hi, As PR114614 shows, the newly added test case gcov-20.c by commit r14-9789-g08a52331803f66 failed on targets which do not support atomic profile update, there would be a message like: warning: target does not support atomic profile update, single mode is selected Since the test

Re: [PATCH 3/3] Add -mcpu=power11 tests

Hi Mike, on 2024/3/20 12:16, Michael Meissner wrote: > This patch adds some simple tests for -mcpu=power11 support. In order to run > these tests, you need an assembler that supports the appropriate option for > supporting the Power11 processor (-mpower11 under Linux or -mpwr11 under AIX). > >

Re: [PATCH] rs6000: Replace OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR [PR101865]

Hi Peter, on 2024/4/6 06:28, Peter Bergner wrote: > This is a cleanup patch in preparation to fixing the real bug in PR101865. > TARGET_DIRECT_MOVE is redundant with TARGET_P8_VECTOR, so alias it to that. > Also replace all usages of OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR > and delete

Re: [PATCH v2] rs6000: Stackoverflow in optimized code on PPC [PR100799]

on 2024/4/3 19:18, Jakub Jelinek wrote: > On Wed, Apr 03, 2024 at 07:01:50PM +0800, Kewen.Lin wrote: >> Thanks for the details on debugging support, but IIUC with this workaround >> being adopted, the debuggability on hidden args are already broken, aren't? > > No. > In

Re: [PATCH v2] rs6000: Stackoverflow in optimized code on PPC [PR100799]

Hi! on 2024/4/3 17:23, Jakub Jelinek wrote: > On Wed, Apr 03, 2024 at 05:02:40PM +0800, Kewen.Lin wrote: >> on 2024/4/3 16:35, Jakub Jelinek wrote: >>> On Wed, Apr 03, 2024 at 01:18:54PM +0800, Kewen.Lin wrote: >>>>> I'd prefer not to remove DECL_ARGUMENTS

Re: [PATCH v2] rs6000: Stackoverflow in optimized code on PPC [PR100799]

Hi Jakub, on 2024/4/3 16:35, Jakub Jelinek wrote: > On Wed, Apr 03, 2024 at 01:18:54PM +0800, Kewen.Lin wrote: >>> I'd prefer not to remove DECL_ARGUMENTS chains, they are valid arguments >>> that just some >>> invalid code doesn't pass. By removing th

Re: [PATCH v2] rs6000: Stackoverflow in optimized code on PPC [PR100799]

Hi Jakub, on 2024/4/2 16:03, Jakub Jelinek wrote: > On Tue, Apr 02, 2024 at 02:12:04PM +0800, Kewen.Lin wrote: >>>>>> The old code for the unused hidden parameter (which was the 9th param) >>>>>> would >>>>>> fall thru to

Re: [PATCH v2] rs6000: Stackoverflow in optimized code on PPC [PR100799]

Hi! on 2024/3/24 02:37, Ajit Agarwal wrote: > > > On 23/03/24 9:33 pm, Peter Bergner wrote: >> On 3/23/24 4:33 AM, Ajit Agarwal wrote: > - else if (align_words < GP_ARG_NUM_REG) > + else if (align_words < GP_ARG_NUM_REG > +|| (cum->hidden_string_length > +

Re: [PATCH v1] rs6000: Stackoverflow in optimized code on PPC [PR100799]

Hi! on 2024/3/22 17:36, Jakub Jelinek wrote: > On Fri, Mar 22, 2024 at 02:55:43PM +0530, Ajit Agarwal wrote: >> rs6000: Stackoverflow in optimized code on PPC [PR100799] >> >> When using FlexiBLAS with OpenBLAS we noticed corruption of >> the parameters passed to OpenBLAS functions. FlexiBLAS >>

Re: [PATCH] rs6000: Fix up setup_incoming_varargs [PR114175]

Hi Jakub, on 2024/3/19 01:21, Jakub Jelinek wrote: > Hi! > > The c23-stdarg-8.c test (as well as the new test below added to cover even > more cases) FAIL on powerpc64le-linux and presumably other powerpc* targets > as well. > Like in the r14-9503-g218d174961 change on x86-64 we need to advance

Re: [PATCH V3] rs6000: Don't ICE when compiling the __builtin_vsx_splat_2di built-in [PR113950]

Hi, on 2024/3/16 04:34, Peter Bergner wrote: > On 3/6/24 3:27 AM, Kewen.Lin wrote: >> on 2024/3/4 02:55, jeevitha wrote: >>> The following patch has been bootstrapped and regtested on >>> powerpc64le-linux. >>>

Re: [PATCH] fix PowerPC < 7 w/ Altivec not to default to power7

Hi, on 2024/3/8 19:33, Rene Rebe wrote: > This might not be the best timing -short before a major release-, > however, Sam just commented on the bug I filled years ago [1], so here > we go: > > Glibc uses .machine to determine assembler optimizations to use. > However, since reworking the rs6000

Re: [PATCH V3] rs6000: Don't ICE when compiling the __builtin_vsx_splat_2di built-in [PR113950]

Hi, on 2024/3/4 02:55, jeevitha wrote: > Hi All, > > The following patch has been bootstrapped and regtested on powerpc64le-linux. > > When we expand the __builtin_vsx_splat_2di function, we were allowing > immediate

Re: [PATCH, rs6000] Add subreg patterns for SImode rotate and mask insert

Hi, on 2024/3/1 10:41, HAO CHEN GUI wrote: > Hi, > This patch fixes regression cases in gcc.target/powerpc/rlwimi-2.c. In > combine pass, SImode (subreg from DImode) lshiftrt is converted to DImode > lshiftrt with an out AND. It matches a DImode rotate and mask insert on > rs6000. > > Trying 2

Re: [PATCH 08/11] rs6000, add tests and documentation for various, built-ins

Hi, on 2024/2/21 01:57, Carl Love wrote: > > GCC maintainers: > > The patch adds documentation a number of built-ins. > > The patch has been tested on Power 10 with no regressions. > > Please let me know if this patch is acceptable for mainline. Thanks. > > Carl >

Re: PATCH 11/11] rs6000, make test vec-cmpne.c a runnable test

Hi, on 2024/2/21 01:58, Carl Love wrote: > GCC maintainers: > > The patch changes the vec-cmpne.c from a compile only test to a runnable > test. The macros to create the functions needed to test the built-ins and > verify the restults are all there in the include file. The .c file just >

Re: [PATCH 09/11] rs6000, add test cases for the vec_cmpne built-ins

Hi, on 2024/2/21 01:57, Carl Love wrote: > GCC maintainers: > > The patch adds test cases for the vec_cmpne of built-ins. > > The patch has been tested on Power 10 with no regressions. > > Please let me know if this patch is acceptable for mainline. Thanks. > > Carl >

Re: [PATCH 07/11] rs6000, __builtin_vsx_xvcmpeq[sp, dp, sp_p] add, documentation and test case

Hi Carl, on 2024/2/21 01:57, Carl Love wrote: > > GCC maintainers: > > The patch adds documentation and test case for the __builtin_vsx_xvcmpeq[sp, > dp, sp_p] built-ins. > > The patch has been tested on Power 10 with no regressions. > > Please let me know if this patch is acceptable for

Re: [PATCH 06/11] rs6000, __builtin_vsx_xxpermdi_1ti add documentation, and test case

Hi Carl, on 2024/2/21 01:57, Carl Love wrote: > GCC maintainers: > > The patch adds documentation and test case for the __builtin_vsx_xxpermdi_1ti > built-in. > > The patch has been tested on Power 10 with no regressions. > > Please let me know if this patch is acceptable for mainline.

Re: [PATCH 05/11] rs6000, __builtin_vsx_xvneg[sp,dp] add documentation, and test cases

Hi, on 2024/2/21 01:56, Carl Love wrote: > GCC maintainers: > > The patch adds documentation and test cases for the __builtin_vsx_xvnegsp, > __builtin_vsx_xvnegdp built-ins. > > The patch has been tested on Power 10 with no regressions. > > Please let me know if this patch is acceptable for

Re: [PATCH 03/11] rs6000, remove duplicated built-ins

on 2024/2/21 01:56, Carl Love wrote: > GCC maintainers: > > There are a number of undocumented built-ins that are duplicates of other > documented built-ins. This patch removes the duplicates so users will only > use the documented built-in. > > The patch has been tested on Power 10 with no

Re: [PATCH 04/11] rs6000, Update comment for the __builtin_vsx_vper*, built-ins.

Hi, on 2024/2/21 01:56, Carl Love wrote: > GCC maintainers: > > The patch expands an existing comment to document that the duplicates are > covered by an overloaded built-in. I am wondering if we should just go ahead > and remove the duplicates? As the below comments Bill placed before, I

Re: [PATCH 02/11] rs6000, fix arguments, add documentation for vector, element conversions

Hi, on 2024/2/21 01:56, Carl Love wrote: > > GCC maintainers: > > This patch fixes the return type for the __builtin_vsx_xvcvdpuxws and > __builtin_vsx_xvcvspuxds built-ins. They were defined as signed but should > have been defined as unsigned. > > The patch has been tested on Power 10

Re: [PATCH 01/11] rs6000, Fix __builtin_vsx_cmple* args and documentation, builtins

Hi, on 2024/2/21 01:55, Carl Love wrote: > > GCC maintainers: > > This patch fixes the arguments and return type for the various > __builtin_vsx_cmple* built-ins. They were defined as signed but should have > been defined as unsigned. > > The patch has been tested on Power 10 with no

Re: [PATCH] rs6000: Don't allow immediate value in the vsx_splat pattern [PR113950]

on 2024/2/27 10:13, Peter Bergner wrote: > On 2/26/24 7:55 PM, Kewen.Lin wrote: >> on 2024/2/26 23:07, Peter Bergner wrote: >>> so I think we should use both Jeevitha's predicate change and >>> your operands[1] change. >> >> Since either the original predic

Re: [PATCH] rs6000: Don't allow immediate value in the vsx_splat pattern [PR113950]

on 2024/2/26 23:07, Peter Bergner wrote: > On 2/26/24 4:49 AM, Kewen.Lin wrote: >> on 2024/2/26 14:18, jeevitha wrote: >>> Hi All, >>> diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md >>> index 6111cc90eb7..e5688ff972a 100644 >>> --- a/

  1   2   3   4   5   6   7   8   9   10   >