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

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] 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

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, 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] 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/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 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 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 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

[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

[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 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

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] 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

[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

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

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] 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 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. >

[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

[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: 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

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 (

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

[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

[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

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

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: [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] 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: [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

[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] 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

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 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: [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]

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

[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 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

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 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 cases

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 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_tree

[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 n

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

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 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 built-in

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. I

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 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] 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 rldim

[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 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_xvcmpeqsp is a du

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

Hi Carl, on 2024/5/25 04:18, Carl Love wrote: > Kewen: > > On 5/14/24 01:43, Kewen.Lin wrote: >> Hi, >> >> on 2024/4/20 05:17, Carl Love wrote: >>> rs6000, Remove __builtin_vsx_xvcvspsxws built-in >>> >>> The built-in __builtin_vsx_xvcvspsxws

Re: [PATCH v2] add explicit ABI and align options to pr88233.c

Hi, on 2024/4/22 17:38, Alexandre Oliva wrote: > Ping? > https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566530.html > (modified version follows) Segher originated this test case, I was expecting he can chime in this. :) > > > We've observed failures of this test on powerpc configurations

Re: [PATCH v2] [testsuite] [powerpc] adjust -m32 counts for fold-vec-extract*

Hi, on 2024/4/22 18:11, Alexandre Oliva wrote: > Ping?-ish > https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619678.html > > It's that time of the year again. The good news is that this is the > last patch in my ppc*-vxworks7* set ;-) > > On May 25, 2023, Segher Boessenkool wrote: > >> On

Re: [PATCHv2] Optab: add isfinite_optab for __builtin_isfinite

Hi, on 2024/5/20 16:15, HAO CHEN GUI wrote: > Hi, > This patch adds an optab for __builtin_isfinite. The finite check can be > implemented on rs6000 by a single instruction. It needs an optab to be > expanded to the certain sequence of instructions. > > The subsequent patches will implement t

Re: [PATCH v3 #1/2] [rs6000] adjust return_pc debug attrs

Hi, on 2024/5/25 20:13, Alexandre Oliva wrote: > On Apr 27, 2023, Alexandre Oliva wrote: > >> On Apr 14, 2023, Alexandre Oliva wrote: >>> On Mar 23, 2023, Alexandre Oliva wrote: This patch introduces infrastructure for targets to add an offset to the label issued after the call_insn

Re: [PATCHv2] Optab: add isfinite_optab for __builtin_isfinite

Hi Haochen, on 2024/5/27 15:22, HAO CHEN GUI wrote: > Hi Kewen, > Thanks for your comments. > > 在 2024/5/27 11:18, Kewen.Lin 写道: >> Does this require "This pattern is not allowed to FAIL."? >> >> I guess yes? Since if it's decided to go with thi

Re: [PATCHv3] Optab: add isfinite_optab for __builtin_isfinite

Hi, on 2024/5/27 20:54, Richard Biener wrote: > On Mon, May 27, 2024 at 11:37 AM HAO CHEN GUI wrote: >> >> Hi, >> This patch adds an optab for __builtin_isfinite. The finite check can be >> implemented on rs6000 by a single instruction. It needs an optab to be >> expanded to the certain sequenc

Re: [PATCHv3] Optab: add isfinite_optab for __builtin_isfinite

on 2024/5/28 20:09, Richard Biener wrote: > On Tue, May 28, 2024 at 9:09 AM Kewen.Lin wrote: >> >> Hi, >> >> on 2024/5/27 20:54, Richard Biener wrote: >>> On Mon, May 27, 2024 at 11:37 AM HAO CHEN GUI wrote: >>>> >>>> Hi, >>>

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

Hi Richi and Joseph, on 2024/5/24 20:23, Richard Biener wrote: > On Fri, May 24, 2024 at 12:20 PM Kewen.Lin wrote: >> btw, the attached patch is bootstrapped and regtested on >> powerpc64-linux-gnu and powerpc64le-linux-gnu with all >> languages on, cross cc1 built we

Re: [PATCH-1, rs6000] Add a new type of CC mode - CCBCD for bcd insns [PR100736, PR114732]

Hi, on 2024/4/30 15:18, HAO CHEN GUI wrote: > Hi, > It's the first patch of a series of patches optimizing CC modes on > rs6000. > > bcd insns set all four bits of a CR field. But it has different single > bit reverse behavior than CCFP's. The forth bit of bcd cr fields is used > to indict ov

Re: [PATCH v2] add explicit ABI and align options to pr88233.c

on 2024/5/29 14:32, Alexandre Oliva wrote: > On May 26, 2024, "Kewen.Lin" wrote: > >> Hi, >> on 2024/4/22 17:38, Alexandre Oliva wrote: >>> Ping? >>> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566530.html >>> (modified version

Re: [PATCH v3 #1/2] [rs6000] adjust return_pc debug attrs

on 2024/5/29 14:52, Alexandre Oliva wrote: > On May 27, 2024, "Kewen.Lin" wrote: > >> I wonder if it's possible to have a test case for this? > > gcc.dg/guality/pr54519-[34].c at -O[1g] are fixed by this patch on Nice! > ppc64le-linux-gnu. Are these the

Re: [PATCH-1, rs6000] Add a new type of CC mode - CCBCD for bcd insns [PR100736, PR114732]

Hi Haochen, on 2024/5/30 11:14, HAO CHEN GUI wrote: > Hi Kewen, > > 在 2024/5/29 13:26, Kewen.Lin 写道: >> I can understand re-using "unordered" and "eq" will save some efforts than >> doing with unspecs, but they are actually RTL codes instead of bits on t

Re: [PATCH 02/52] d: Replace use of LONG_DOUBLE_TYPE_SIZE

Hi Iain, on 2024/6/3 16:40, Iain Buclaw wrote: > Excerpts from Kewen Lin's message of Juni 3, 2024 5:00 am: >> Joseph pointed out "floating types should have their mode, >> not a poorly defined precision value" in the discussion[1], >> as he and Richi suggested, the existing macros >> {FLOAT,{,LON

Re: [PATCH 09/52] Replace {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE with new hook mode_for_floating_type

Hi Richi, on 2024/6/3 14:49, Richard Biener wrote: > On Mon, Jun 3, 2024 at 5:02 AM Kewen Lin wrote: >> >> Currently how we determine which mode will be used for a >> floating point type is that for a given type precision >> (size) call mode_for_size to get the first mode which has >> this size i

Re: [PATCH 51/52] sparc: New hook implementation sparc_c_mode_for_floating_type

Hi Eric, on 2024/6/3 17:02, Eric Botcazou wrote: >> * config/sparc/sparc.cc (sparc_c_mode_for_floating_type): New >> (TARGET_C_MODE_FOR_FLOATING_TYPE): New macro. >> (FLOAT_TYPE_SIZE): Remove. >> (DOUBLE_TYPE_SIZE): Likewise. >> (LONG_DOUBLE_TYPE_SIZE): Rename to ... >>

Re: [PATCH 17/52] gcn: Remove macros {FLOAT, DOUBLE, LONG_DOUBLE}_TYPE_SIZE

Hi Andrew, on 2024/6/3 17:14, Andrew Stubbs wrote: > On 03/06/2024 04:01, Kewen Lin wrote: >> This is to remove macros {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE >> defines in gcn port. >> >> gcc/ChangeLog: >> >> * config/gcn/gcn.h (FLOAT_TYPE_SIZE): Remove. >> (DOUBLE_TYPE_SIZE): Likewise. >> (

[PATCH 02/52 v2] d: Replace use of LONG_DOUBLE_TYPE_SIZE

Hi Iain, on 2024/6/3 22:39, Iain Buclaw wrote: > Excerpts from Kewen.Lin's message of Juni 3, 2024 10:57 am: >> Hi Iain, >> >> on 2024/6/3 16:40, Iain Buclaw wrote: >>> Excerpts from Kewen Lin's message of Juni 3, 2024 5:00 am: Joseph pointed out "floating types should have their mode, n

Re: [PATCH 06/52] m2: Replace uses of {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE

Hi Joseph and Gaius, on 2024/6/4 02:02, Joseph Myers wrote: > On Sun, 2 Jun 2024, Kewen Lin wrote: > >> diff --git a/gcc/m2/gm2-gcc/m2type.cc b/gcc/m2/gm2-gcc/m2type.cc >> index 571923c08ef..d52cbdf0b99 100644 >> --- a/gcc/m2/gm2-gcc/m2type.cc >> +++ b/gcc/m2/gm2-gcc/m2type.cc >> @@ -1420,7 +1420

[PATCH 09/52 v2] Replace {FLOAT, {, LONG_}DOUBLE}_TYPE_SIZE with new hook mode_for_floating_type

Hi Joseph, on 2024/6/4 01:59, Joseph Myers wrote: > On Sun, 2 Jun 2024, Kewen Lin wrote: > >> +value less than or equal to mode precision of the mode used for C type >> +@code{long double} (from hook @code{targetm.c.mode_for_floating_type} >> +with tree_index TI_LONG_DOUBLE_TYPE). If you do not

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

Hi Rene, on 2024/5/31 22:57, Rene Rebe wrote: > Hi Kewen, > > thank you for your reply. > >> 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: >>> >>> Gli

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

Hi, on 2024/5/29 23:56, Carl Love wrote: > This patch was updated per the feedback comment from the previous version in > series 2. > > Carl > --- > > rs6000, fix error in unsigned vector float to unsi

Re: [PATCH 7/13 ver 3] rs6000, add overloaded vec_sel with int128 arguments

Hi, on 2024/5/30 00:03, Carl Love wrote: > This was patch 6 in the previous series. Updated the documentation file per > the comments. No functional changes to the patch. > > Carl > > > rs6000, add overloa

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

Hi, on 2024/5/30 00:05, Carl Love wrote: > This was patch 7 in the previous series. Patch was updated to address the > feedback comments. > > Carl > > > rs6000, remove the vec_xxsel built-ins,

Re: [PATCH 9/13 ver 3] rs6000, remove __builtin_vsx_vperm_* built-ins

Hi, on 2024/5/30 00:06, Carl Love wrote: > This was patch 8 in the previous series. Updated patch per the feedback > comments. > > Carl > > > rs6000, remove __builtin_vsx_vperm_* built-ins > > Th

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

Hi, on 2024/5/30 00:10, Carl Love wrote: > This was patch 10 from the previous series. The patch was updated to > address feedback comments. > > Carl > --- > > rs6000, extend vec_xxpermdi built-in for __int128 args >

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

Hi, on 2024/5/30 00:16, Carl Love wrote: > This was patch 13 from the previous series. Note the previous series patch > 12 was dropped. This patch is the same as the previous version. The > additional work to remove __builtin_vec_set_v1ti, __builtin_vec_set_v2di, > __builtin_vec_set_v2d pe

Re: [PATCH 12/13 ver 3] rs6000, remove __builtin_vsx_xvcmpeqsp_p built-in

Hi Carl, on 2024/5/30 00:11, Carl Love wrote: > This was patch 11 from the previous series. Patch was updated to address > feedback comments. > >Carl > -- > > rs6000, remove __builtin_vsx_xvcmpeqsp_p built-in > >

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

Hi Carl, on 2024/5/29 23:52, Carl Love wrote: > This patch was approved in the previous series. There are no changes to this > patch. Reposting for completeness. I guess you can just push the approved ones, as there is no dependency between any two of them? It can help to reduce the size of

Re: [PATCH 5/13 ver 3] rs6000, Remove redundant float/double type conversions

Hi, on 2024/5/30 00:00, Carl Love wrote: > This is a new patch to removed the built-ins that were inadvertently missing > in the previous series. > > Carl > -- > > rs6000, Remove redundant float/double ty

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

Hi, on 2024/5/29 23:58, Carl Love wrote: > Updated the patch per the feedback comments from the previous version. > > Carl > --- > > rs6000, extend the current vec_{un,}signed{e,o} built-ins > > The built-ins

[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

[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] 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] 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

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. >

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 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

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/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

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 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/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

[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

[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

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, >>>> >>

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