Re: [PATCH] ira: Skip some pseudos in move_unallocated_pseudos

Hi Segher, on 2020/12/22 下午9:55, Segher Boessenkool wrote: > Hi! > > Just a dumb formatting comment: > > On Tue, Dec 22, 2020 at 04:05:39PM +0800, Kewen.Lin wrote: >> This patch is to make move_unallocated_pseudos consistent >> to what we have in function find_moveable_pseudos, where we >> recor

[PATCH] sccvn: Consider def BB in rpo_vn_valueize [PR98464]

Hi, As PR98464 shows, this patch is to make rpo_vn_valueize consider the definition basic block of name, to sync with what we do in function eliminate_stmt. Bootstrapped/regtested on powerpc64le-linux-gnu P9. Full SPEC2017 build/run passed on P9. BR, Kewen gcc/ChangeLog: PR tree-optim

Re: [PATCH] sccvn: Consider def BB in rpo_vn_valueize [PR98464]

on 2020/12/31 下午6:01, Richard Biener wrote: > On December 31, 2020 8:02:37 AM GMT+01:00, "Kewen.Lin" > wrote: >> Hi, >> >> As PR98464 shows, this patch is to make rpo_vn_valueize >> consider the definition basic block of name, to sync >> with what we do in function eliminate_stmt. >> >> Bootstrap

Re: [PATCH] ira: Skip some pseudos in move_unallocated_pseudos

Hi Jeff, on 2021/1/5 上午7:13, Jeff Law wrote: > > > On 12/22/20 11:40 PM, Kewen.Lin via Gcc-patches wrote: >> Hi Segher, >> >> on 2020/12/22 下午9:55, Segher Boessenkool wrote: >>> Hi! >>> >>> Just a dumb formatting comment: >>>

Re: [PATCH] ira: Skip some pseudos in move_unallocated_pseudos

on 2021/1/6 上午2:19, Jeff Law wrote: > > > On 1/4/21 7:36 PM, Kewen.Lin wrote: >> Hi Jeff, >> >> on 2021/1/5 上午7:13, Jeff Law wrote: >>> >>> On 12/22/20 11:40 PM, Kewen.Lin via Gcc-patches wrote: >>>> Hi Segher, >>>> >>&g

PING^1 [PATCH] combine: zeroing cost for new copies

Hi, I'd like to gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561413.html BR, Kewen on 2020/12/9 下午5:49, Kewen.Lin via Gcc-patches wrote: > Hi, > > This patch is to treat those new pseudo-to-pseudo copies > after hard-reg-to-pseudo-copy as

PING^1 [PATCH/RFC] combine: Tweak the condition of last_set invalidation

Hi, I'd like to gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562015.html BR, Kewen on 2020/12/16 下午4:49, Kewen.Lin via Gcc-patches wrote: > Hi, > > When I was investigating unsigned int vec_init issue on Power, > I happened to find there seems

PING^1 [PATCH] rs6000: Use rldimi for vec init instead of shift + ior

Hi, I'd like to gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562407.html BR, Kewen on 2020/12/22 下午4:08, Kewen.Lin via Gcc-patches wrote: > Hi, > > This patch is to make unsigned int vector init go with > rldimi to merge two integers instead

PING^7 [PATCH 1/4] unroll: Add middle-end unroll factor estimation

Hi, Gentle ping^7 for: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546698.html BR, Kewen on 2020/12/17 上午10:58, Kewen.Lin via Gcc-patches wrote: > Hi, > > Gentle ping^6 for: > > https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546698.html > > BR, > Kewen &

Re: [PATCH] rs6000: Use rldimi for vec init instead of shift + ior

Hi Segher, on 2021/1/15 上午8:50, Segher Boessenkool wrote: > Hi! > > On Tue, Dec 22, 2020 at 04:08:26PM +0800, Kewen.Lin wrote: >> This patch is to make unsigned int vector init go with >> rldimi to merge two integers instead of shift and ior. >> >> I tried to use nonzero_bits in md file to make i

Re: [PATCH] combine: zeroing cost for new copies

Hi Segher, Thanks for the comments! on 2021/1/15 上午4:43, Segher Boessenkool wrote: > Hi! > > On Wed, Dec 09, 2020 at 05:49:53PM +0800, Kewen.Lin wrote: >> This patch is to treat those new pseudo-to-pseudo copies >> after hard-reg-to-pseudo-copy as zero costs. The >> justification is that these

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

Hi Segher, Thanks for the comments! on 2021/1/15 上午8:22, Segher Boessenkool wrote: > Hi! > > On Wed, Dec 16, 2020 at 04:49:49PM +0800, Kewen.Lin wrote: >> When I was investigating unsigned int vec_init issue on Power, >> I happened to find there seems something we can enhance in how >> combine p

[PATCH] vect: Use factored nloads for load cost modeling [PR82255]

Hi, This patch follows Richard's suggestion in the thread discussion[1], it's to factor out the nloads computation in vectorizable_load for strided access, to ensure we can obtain the consistent information when estimating the costs. btw, the reason why I didn't try to save the information into s

Re: [PATCH] combine: zeroing cost for new copies

Hi Segher, on 2021/1/15 下午2:49, Kewen.Lin via Gcc-patches wrote: > on 2021/1/15 上午4:43, Segher Boessenkool wrote: [snip...] >> Long ago I had the following patch for this. Not sure why I never >> submitted it, maybe there is something wronmg with it? >> > > If you

Re: [PATCH] rs6000: Use rldimi for vec init instead of shift + ior

on 2021/1/15 下午2:40, Kewen.Lin via Gcc-patches wrote: > Hi Segher, > > on 2021/1/15 上午8:50, Segher Boessenkool wrote: >> Hi! >> >> On Tue, Dec 22, 2020 at 04:08:26PM +0800, Kewen.Lin wrote: >>> This patch is to make unsigned int vector init go with >>

Re: [PATCH] vect: Use factored nloads for load cost modeling [PR82255]

Hi Richard, on 2021/1/15 下午8:03, Richard Biener wrote: > On Fri, Jan 15, 2021 at 9:11 AM Kewen.Lin wrote: >> >> Hi, >> >> This patch follows Richard's suggestion in the thread discussion[1], >> it's to factor out the nloads computation in vectorizable_load for >> strided access, to ensure we can

[PATCH 0/4] vect: Rename/refactor some codes related to fully masking

Hi all, As Richard suggested in vector with length reviews here https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547077.html, this series is responsible for some renaming and refactoring related to existing fully masking supports. Since we are going to introduce length-based partial vectorizat

[PATCH 1/4] vect: Rename can_fully_mask_p to can_use_partial_vectors_p

gcc/ChangeLog: * tree-vect-loop.c (_loop_vec_info::_loop_vec_info): Rename can_fully_mask_p to can_use_partial_vectors_p. (vect_analyze_loop_2): Rename LOOP_VINFO_CAN_FULLY_MASK_P to LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P. Rename saved_can_fully_mask_p to sav

[PATCH 2/4] vect: Rename fully_masked_p to using_partial_vectors_p

gcc/ChangeLog: * tree-vect-loop-manip.c (vect_set_loop_condition): Rename LOOP_VINFO_FULLY_MASKED_P to LOOP_VINFO_USING_PARTIAL_VECTORS_P. (vect_gen_vector_loop_niters): Likewise. (vect_do_peeling): Likewise. * tree-vect-loop.c (_loop_vec_info::_loop_vec_inf

[PATCH 3/4] vect: Rename things related to rgroup_masks

gcc/ChangeLog: * tree-vect-loop-manip.c (vect_set_loop_mask): Renamed to ... (vect_set_loop_control): ... this. (vect_maybe_permute_loop_masks): Rename rgroup_masks related things. (vect_set_loop_masks_directly): Renamed to ... (vect_set_loop_controls_direct

[PATCH 4/4] vect: Factor out and rename some functions/macros

gcc/ChangeLog: * tree-vect-loop-manip.c (vect_set_loop_controls_directly): Rename LOOP_VINFO_MASK_COMPARE_TYPE to LOOP_VINFO_COMPARE_TYPE. Rename LOOP_VINFO_MASK_IV_TYPE to LOOP_VINFO_IV_TYPE. (vect_set_loop_condition_masked): Renamed to ... (vect_set_loop_

[PATCH 1/7 V2] ifn/optabs: Support vector load/store with length

V2: Convert the length to targetm.vectorize.length_mode in related IFN expand functions. btw, since it depends on this hook now, it should be committed after the hook patch if accepted in future. gcc/ChangeLog: 2020-MM-DD Kewen Lin * doc/md.texi (lenload@var{m}@var{n}): Document.

[PATCH 2/7 V2] rs6000: lenload/lenstore optab support

V2: Update the define_expand to use QImode. gcc/ChangeLog: 2020-MM-DD Kewen Lin * config/rs6000/vsx.md (lenloadqi): New define_expand. (lenstoreqi): Likewise. --- gcc/config/rs6000/vsx.md | 32 1 file changed, 32 insertions(+) diff --git a/

[PATCH 4/7 V2] hook/rs6000: Add vectorize length mode for vector with length

v2: Update rs6000 length_mode hook to QImode, also update description of the hook. gcc/ChangeLog: 2020-MM-DD Kewen Lin * config/rs6000/rs6000.c (TARGET_VECTORIZE_LENGTH_MODE): New macro. * doc/tm.texi: Regenerate. * doc/tm.texi.in: New hook. * target.def: Like

[PATCH 5/7 v4] vect: Support vector load/store with length in vectorizer

Hi all, Against v3, v4 mainly based on Richard's comments and consists of changes: - split out some renaming and refactoring. - use QImode for length. - update the iv type determination. - introduce factor into rgroup_controls. - use using_partial_vectors_p for both approaches. Bootstra

[PATCH 1/7 V3] ifn/optabs: Support vector load/store with length

on 2020/6/10 下午5:22, Richard Sandiford wrote: > "Kewen.Lin" writes: >> @@ -2497,6 +2499,9 @@ expand_mask_load_optab_fn (internal_fn, gcall *stmt, >> convert_optab optab) >> >>if (optab == vec_mask_load_lanes_optab) >> icode = get_multi_vector_move (type, optab); >> + else if (optab ==

[PATCH 2/7 V3] rs6000: lenload/lenstore optab support

V3: Update the define_expand as optab changes. gcc/ChangeLog: 2020-MM-DD Kewen Lin * config/rs6000/vsx.md (lenload): New define_expand. (lenstore): Likewise. --- gcc/config/rs6000/vsx.md | 32 1 file changed, 32 insertions(+) diff --git a/

[PATCH 4/4 V2] vect: Factor out and rename some functions/macros

on 2020/6/11 上午12:58, Richard Sandiford wrote: > "Kewen.Lin" writes: >> diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c >> index ca68d04a919..1fac5898525 100644 >> --- a/gcc/tree-vect-loop-manip.c >> +++ b/gcc/tree-vect-loop-manip.c >> @@ -420,8 +420,8 @@ vect_set_loop_control

Re: [PATCH 2/7 V3] rs6000: lenload/lenstore optab support

Hi Segher, on 2020/6/12 上午6:55, Segher Boessenkool wrote: > Hi! > > On Wed, Jun 10, 2020 at 08:39:19PM +0800, Kewen.Lin wrote: >> +;; Define optab for vector access with length vectorization exploitation. >> +(define_expand "lenload" >> + [(match_operand:VEC_A 0 "vlogical_operand") >> + (match

[PATCH 5/7 v5] vect: Support vector load/store with length in vectorizer

Hi, v5 changes against v4: - Updated the conditions of clearing LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P in vectorizable_condition (which fixed the aarch reg failure). - Rebased and updated some macro and function names as the renaming/refactoring patch. - Updated some comments and dumpi

[PATCH 1/7 V4] ifn/optabs: Support vector load/store with length

Hi, v4: Update len_load_direct/len_store_direct to align with direct optab. v3: Get rid of length mode hook. Thanks for reviewing! BR, Kewen --- gcc/ChangeLog: 2020-MM-DD Kewen Lin * doc/md.texi (lenload@var{m}): Document. (lenstore@var{m}): Likewise. * internal-fn.

[PATCH 1/7 v5] ifn/optabs: Support vector load/store with length

Hi Richard, Thanks for your comments! on 2020/6/23 上午3:59, Richard Sandiford wrote: > "Kewen.Lin" writes: >> @@ -5167,6 +5167,24 @@ mode @var{n}. >> >> This pattern is not allowed to @code{FAIL}. >> >> +@cindex @code{lenload@var{m}} instruction pattern >> +@item @samp{lenload@var{m}} >> +Pe

[PATCH 2/7 v4] rs6000: lenload/lenstore optab support

Hi, V4: Update define_expand names as optab name changes. V3: Update the define_expand as optab changes. BR, Kewen - gcc/ChangeLog: 2020-MM-DD Kewen Lin * config/rs6000/vsx.md (len_load_): New define_expand. (len_store_): Likewise. diff --git a/gcc/config/rs6000/vsx.md

[RFC/PATCH] IFN: Fix mask_{load,store} optab support macros

Hi, When I am working on IFNs for vector with length, I noticed that the current optab support query for mask_load/mask_store looks unexpected. The mask_load/mask_store requires two modes for convert_optab query, but the macros direct_mask_{load,store}_optab_supported_p uses direct_optab_supported

[PATCH 2/7 v5] rs6000: lenload/lenstore optab support

Hi, V5: Like V4. V4: Update define_expand names as optab name changes. V3: Update the define_expand as optab changes. BR, Kewen -- gcc/ChangeLog: 2020-MM-DD Kewen Lin * config/rs6000/vsx.md (len_load_v16qi): New define_expand. (len_store_v16qi): Likewise. diff --git a/

[PATCH 5/7 v6] vect: Support vector load/store with length in vectorizer

Hi, v6 changes against v5: - As len_load/store optab changes, added function can_vec_len_load_store_p and vect_get_same_size_vec_for_len. - Updated several places like vectoriable_load/store for optab changes. v5 changes against v4: - Updated the conditions of clearing LOOP_VINFO_CAN_US

[PATCH 1/7 v6] ifn/optabs: Support vector load/store with length

Hi Richard S./Richi/Jim/Segher, Thanks a lot for your comments to make this patch more solid. Based on our discussion, for the vector load/store with length optab, the length unit would be measured in lanes by default. For the targets which support length measured in bytes like Power, they should

[PATCH] testsuite: Ignore line no. for BB vectorization message

Hi, In my testing with vector with length, I happened to find the case g++.dg/vect/slp-pr56812.cc need to be fixed a bit with line number neglection since the message for basic block vectorization looks like: slp-pr56812.cc:19:1: optimized: basic block part vectorized using 16 byte vectors whi

[PATCH 1/7 v7] ifn/optabs: Support vector load/store with length

Hi Richard, Thanks for the comments! on 2020/6/29 下午6:07, Richard Sandiford wrote: > Thanks for the update. I agree with the summary of the IRC discussion > except for… > > "Kewen.Lin" writes: >> Hi Richard S./Richi/Jim/Segher, >> >> Thanks a lot for your comments to make this patch more solid

Re: [PATCH 5/7 v6] vect: Support vector load/store with length in vectorizer

Hi Richard, Many thanks for your great review comments! on 2020/7/1 上午3:53, Richard Sandiford wrote: > "Kewen.Lin" writes: >> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi >> index 06a04e3d7dd..284c15705ea 100644 >> --- a/gcc/doc/invoke.texi >> +++ b/gcc/doc/invoke.texi >> @@ -13389,6 +

[PATCH 1/7 v8] ifn/optabs: Support vector load/store with length

Hi Richard, on 2020/6/30 下午11:32, Richard Sandiford wrote: > "Kewen.Lin" writes: >> Hi Richard, >> >> Thanks for the comments! >> >> on 2020/6/29 下午6:07, Richard Sandiford wrote: >>> Thanks for the update. I agree with the summary of the IRC discussion >>> except for… >>> >>> "Kewen.Lin" writes

Re: [PATCH 5/7 v6] vect: Support vector load/store with length in vectorizer

Hi Richard, on 2020/7/1 下午11:17, Richard Sandiford wrote: > "Kewen.Lin" writes: >> on 2020/7/1 上午3:53, Richard Sandiford wrote: >>> "Kewen.Lin" writes: poly_uint64 vf = LOOP_VINFO_VECT_FACTOR (loop_vinfo); + tree length_limit = NULL_TREE; + /* For length, we need length_limit

PING^5 [PATCH 1/4] unroll: Add middle-end unroll factor estimation

Hi, Gentle ping^5 for: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546698.html BR, Kewen on 2020/11/2 下午5:13, Kewen.Lin via Gcc-patches wrote: > Hi, > > Gentle ping^4 this: > > https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546698.html > > BR, > Kewen &

[PATCH] rs6000: Fix p8_mtvsrd_df's insn type

Hi, The insn type of p8_mtvsrd_df looks missed to be updated with mtvsr. Here I supposed mtvsrd's all usages should be with the same insn type. This patch is to fix its current insn type mfvsr by mtvsr. Is it ok for trunk? BR, Kewen - gcc/ChangeLog: * config/rs6000/rs6000.md (p8_m

test: Update cases for vect_partial_vectors_usage_1

Hi, I adjusted some vectorization test cases for vect_partial_vectors_usage_1 before, but as exposed in the recent testings, some of them need to be adjusted again. The reason is that the commit r11-3393 improved the epilogue loop handling of partial vectors and we won't use partial vectors to ve

[PATCH] rs6000: Set param_vect_partial_vector_usage as 1 for P10

Hi, This patch is to set param_vect_partial_vector_usage as 1 on P10 by default. Due to the unexpected performance on Power9 of those vector with length instructions, we didn't enable vectorization with partial vectors before. Some recent testings show that they perform expectedly on Power10 now

[PATCH/RFC] rs6000: Disable HTM for Power10 and later

Hi, During previous Power10 testing, I noticed that ISA 3.1 has dropped TM support. I think we should not generate TM related instructions for Power10 and later, or no? This patch is to turn off HTM support once we know the cpu setting is power10 or later, and warn something if the explicit opti

[PATCH v2] rs6000: Disable HTM for Power10 and later

Hi Segher, on 2020/11/27 上午5:11, Segher Boessenkool wrote: > Hi! > > On Thu, Nov 26, 2020 at 06:15:04PM +0800, Kewen.Lin wrote: >> During previous Power10 testing, I noticed that ISA 3.1 has >> dropped TM support. I think we should not generate TM >> related instructions for Power10 and later, o

Re: [PATCH v2] rs6000: Disable HTM for Power10 and later

Hi Segher, on 2020/12/1 上午4:49, Segher Boessenkool wrote: > Hi! > > On Mon, Nov 30, 2020 at 06:36:30PM +0800, Kewen.Lin wrote: >> --- a/gcc/config/rs6000/rs6000-cpus.def >> +++ b/gcc/config/rs6000/rs6000-cpus.def >> @@ -51,7 +51,6 @@ >> | OPTION_MASK_CRYPTO

[PATCH] rs6000: Use subreg for QI/HI vector init

Hi, This patch is to use paradoxical subreg instead of zero_extend for promoting QI/HI to SI/DI when we want to construct one vector with these modes. Since we do the gpr->vsx movement and vector merge or pack later, the high part is useless and safe to use paradoxical subreg. It can avoid useles

[PATCH] combine: zeroing cost for new copies

Hi, This patch is to treat those new pseudo-to-pseudo copies after hard-reg-to-pseudo-copy as zero costs. The justification is that these new copies are closely after the corresponding hard-reg-to-pseudo-copy insns, register allocation should be able to coalesce them and get them eliminated. Now

[PATCH v2] pass: Run cleanup passes before SLP [PR96789]

Hi! >> Can you repeat the compile-time measurement there? I also wonder >> whether we should worry about compile-time at -O[12] when SLP is not run. >> Thus, probably rename the cleanup pass to pre_slp_scalar_cleanup and >> gate it on && flag_slp_vectorize > > Good idea, will evaluate it. > So

PING^1 [PATCH v2] rs6000: Use direct move for char/short vector CTOR [PR96933]

Hi, I'd like to gentle ping this patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553555.html BR, Kewen on 2020/9/10 上午11:19, Kewen.Lin via Gcc-patches wrote: > Hi, > > As Segher's suggestion in the PR, for 128bit_direct_move, this new > version lever

PING^3 [PATCH 1/4] unroll: Add middle-end unroll factor estimation

Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546698.html BR, Kewen on 2020/9/15 下午3:44, Kewen.Lin via Gcc-patches wrote: > Hi, > > Gentle ping this: > > https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546698.html > > BR, > Kewen

[PATCH] vect: Remove redundant LOOP_VINFO_FULLY_MASKED_P

Hi, This is a very trivial patch, it's to remove a redundant LOOP_VINFO_FULLY_MASKED_P condition check which will be checked in vect_use_loop_mask_for_alignment_p. Is it OK for trunk? BR, Kewen - gcc/ChangeLog: * tree-vect-loop.c (vect_transform_loop): Remove the redundant L

[PATCH] rtl: Try to remove EH edges after {pro,epi}logue generation [PR90259]

Hi, After prologue and epilogue generation, the judgement on whether one memory access onto stack frame may trap or not could change, since we get more exact stack information by now. As PR90259 shows, some memory access becomes impossible to trap any more after prologue and epilogue generation,

Re: [PATCH] rtl: Try to remove EH edges after {pro,epi}logue generation [PR90259]

Hi Richi and Eric, Thanks for your reviews and comments! on 2022/11/8 18:37, Eric Botcazou wrote: >> It looks reasonable - OK if the others CCed have no comments. > > My only comment is that it needs to be tested with languages enabling -fnon- > call-exceptions by default (Ada & Go), if not alre

Re: [PATCH] rtl: Try to remove EH edges after {pro,epi}logue generation [PR90259]

on 2022/11/9 15:56, Eric Botcazou wrote: >> The previous testings on powerpc64{,le}-linux-gnu covered language Go, but >> not Ada. I re-tested it with languages c,c++,fortran,objc,obj-c++,go,ada >> on powerpc64le-linux-gnu, the result looked good. Both x86 and aarch64 >> cfarm machines which I us

PING^2 [PATCH] Adjust the symbol for SECTION_LINK_ORDER linked_to section [PR99889]

Hi, Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600190.html Any comments are highly appreciated. BR, Kewen on 2022/9/28 13:41, Kewen.Lin via Gcc-patches wrote: > Hi, > > Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600190.html > &

Re: [PATCH] rtl: Try to remove EH edges after {pro,epi}logue generation [PR90259]

on 2022/11/10 11:30, Kewen.Lin wrote: > on 2022/11/9 15:56, Eric Botcazou wrote: >>> The previous testings on powerpc64{,le}-linux-gnu covered language Go, but >>> not Ada. I re-tested it with languages c,c++,fortran,objc,obj-c++,go,ada >>> on powerpc64le-linux-gnu, the result looked good. Both x

[PATCH 1/2] rs6000: Emit vector fp comparison directly in rs6000_emit_vector_compare

Hi, All kinds of vector float comparison operators have been supported in one rtl comparison pattern as vector.md, we can just emit an rtx comparison insn with the given comparison operator in function rs6000_emit_vector_compare instead of checking and handling the reverse condition cases. This i

[PATCH 2/2] rs6000: Refine integer comparison handlings in rs6000_emit_vector_compare

Hi, The current handlings in rs6000_emit_vector_compare is a bit complicated to me, especially after we emit vector float comparison insn with the given code directly. This patch is to refine the handlings for vector integer comparison operators, it becomes not recursive, and we don't need the he

[PATCH] Fix typo in gimple_fold_partial_load_store_mem_ref

Hi, As Robin spotted, my recent commit r13-3716 caused an ICE on s390 if vector access with length is enabled there (his patch for the enablement hasn't been committed yet). The failure is caused by one stupid typo, the bias on s390 is -1, so the assertion should use tree_fits_shwi_p rather than

Re: [PATCH 1/2] rs6000: Emit vector fp comparison directly in rs6000_emit_vector_compare

Hi Segher, Thanks for the comments! on 2022/11/17 02:44, Segher Boessenkool wrote: > Hi! > > On Wed, Nov 16, 2022 at 02:48:25PM +0800, Kewen.Lin wrote: >> * config/rs6000/rs6000.cc (rs6000_emit_vector_compare_inner): Remove >> float only comparison operators. > > Why? Is that correct

Re: [PATCH 2/2] rs6000: Refine integer comparison handlings in rs6000_emit_vector_compare

Hi Segher, Thanks for the comments! on 2022/11/17 02:58, Segher Boessenkool wrote: > Hi! > > On Wed, Nov 16, 2022 at 02:51:04PM +0800, Kewen.Lin wrote: >> The current handlings in rs6000_emit_vector_compare is a bit >> complicated to me, especially after we emit vector float >> comparison insn w

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

Hi Haochen, on 2023/4/18 11:13, HAO CHEN GUI via Gcc-patches wrote: > Hi, > This patch adds ppc_cpu_supports_hw into explicit name checking in > proc is-effective-target-keyword. So ppc_cpu_supports_hw can be used > as a target selector in test directives. I think this is the prerequisite of th

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

Hi Haochen, on 2023/4/18 11:13, HAO CHEN GUI wrote: > Hi, > This patch xfails a float128 comparison test case on powerpc64 > that fails due to a longstanding issue with floating-point > compares. > > See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684 for more > information. > > The cas

Re: [PATCH] PR testsuite/106879 FAIL: gcc.dg/vect/bb-slp-layout-19.c on powerpc64

Hi Jeff, on 2023/4/19 10:03, Jiufu Guo wrote: > Hi, > > On P7, option -mno-allow-movmisalign is added during testing, which > prevents slp happen on the case. > > Like Like PR65484 and PR87306, this patch use vect_hw_misalig to guard Dup like... ~~ missing the

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

Hi, on 2023/4/20 14:04, HAO CHEN GUI wrote: > Hi, > This patch adds ppc_cpu_supports_hw into explicit name checking in > proc is-effective-target-keyword. So ppc_cpu_supports_hw can be used > as a target selector in test directives. It's required by patch2 of > this issue. OK for trunk, thanks!

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

Hi, on 2023/4/20 14:04, HAO CHEN GUI wrote: > Hi, > This patch xfails a float128 comparison test case on powerpc64 > that fails due to a longstanding issue with floating-point > compares. > > See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684 for more > information. > > The patch passe

Re: [PATCH] powerpc: Fix up *branch_anddi3_dot for -m32 -mpowerpc64 [PR109566]

Hi Jakub, Thanks for the prompt fix! on 2023/4/24 23:54, Jakub Jelinek wrote: > Hi! > > The following testcase reduced from newlib ICEs on powerpc-linux, > with -O2 -m32 -mpowerpc64 since r12-6433 PR102239 optimization was > added and on the original testcase since some ranger improvements in >

Re: [PATCH, rs6000] Splat vector small V2DI constants with ISA 2.07 instructions [PR104124]

Hi Haochen, on 2022/9/21 13:13, HAO CHEN GUI wrote: > Hi, > This patch adds a new insn for vector splat with small V2DI constants on P8. > If the value of constant is in RANGE (-16, 15) and not 0 or -1, it can be > loaded > with vspltisw and vupkhsw on P8. It should be efficient than loading ve

Re: [PATCH V3] rs6000: Load high and low part of 64bit constant independently

Hi Jeff, on 2023/1/4 14:51, Jiufu Guo wrote: > Hi, > > Compare with previous version, this patch updates the comments only. > https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608293.html > > For a complicate 64bit constant, below is one instruction-sequence to > build: > lis 9,0x800

Re: [PATCH V4] VECT: Add decrement IV iteration loop control by variable amount support

Hi, on 2023/5/4 21:25, juzhe.zh...@rivai.ai wrote: > From: Ju-Zhe Zhong > > This patch is fixing V3 patch: > https://patchwork.sourceware.org/project/gcc/patch/20230407014741.139387-1-juzhe.zh...@rivai.ai/ > > Fix issues according to Richard Sandiford && Richard Biener. > > 1. Rename WHILE_LEN

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

Hi Haochen, on 2023/1/4 14:16, HAO CHEN GUI wrote: > Hi, > This patch changes the return type of __builtin_vsx_scalar_extract_exp > from const signed long to const signed int, as the exponent can be put in > a signed int. It is also inline with the external interface definition of > the bif. The

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

Hi Haochen, on 2023/1/4 14:16, HAO CHEN GUI wrote: > Hi, > This patch changes the return type of __builtin_vsx_scalar_extract_sig > from const signed long to const signed long long, so that it can be called > with "-m32/-mpowerpc64" option. The bif needs TARGET_POWERPC64 instead of > TARGET_64BI

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

Hi Haochen, on 2023/1/4 14:17, HAO CHEN GUI wrote: > Hi, > This patch changes the mode of exponent to GPR in scalar insert exp > pattern, as the exponent can be put into a 32-bit register. Also the > condition check is changed from TARGET_64BIT to TARGET_POWERPC64. > > The test cases are modi

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

Hi Haochen, on 2023/1/4 14:17, HAO CHEN GUI wrote: > Hi, > "ilp32" is used in these test cases to make sure test cases only run on a > 32-bit environment. Unfortunately, these cases also run with > "-m32/-mpowerpc64" which causes unexpected errors. This patch changes the > target check to skip i

Re: [PATCH V4] VECT: Add decrement IV iteration loop control by variable amount support

Hi Juzhe, > Hi, Kewen. > >>> Sorry for chiming in, I had some concern here. >>> We already have some handlings for partial vector in length in >>> vect_set_loop_controls_directly >>>(actually it deals with both mask and length), the proposed >>>vect_set_loop_controls_by_select_vl >>>for select_

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

Hi Haochen, on 2022/5/24 16:45, HAO CHEN GUI wrote: > Hi, >This patch adds V1TI mode into a new mode iterator used in vector > comparison and rotation expands. Without the patch, the comparisons > between two vector __int128 are converted to scalar comparisons. The > code is suboptimal. The pa

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

Hi Haochen, on 2022/5/26 13:30, HAO CHEN GUI wrote: > Kewen, > Thanks so much for your advice. Just one question about effective-target. > > For the test cases, it needs both power10_ok and int128 support. I saw some > existing test cases have these two checks as well. But I wonder if power10

Re: [PATCH, rs6000] Clean up the option_mask defines (part 1)

Hi Will, on 2022/5/26 04:25, will schmidt via Gcc-patches wrote: > [PATCH, rs6000] Clean up the option_mask defines > > Hi, > > We have an assortment of MASK and OPTION_MASK #defines throughout > the rs6000 code, MASK_ALTIVEC and OPTION_MASK_ALTIVEC as an example. > > We currently #define t

Re: [PATCH, rs6000] Clean up the option_mask defines (part 1)

on 2022/5/26 14:12, Kewen.Lin via Gcc-patches wrote: > Hi Will, > > on 2022/5/26 04:25, will schmidt via Gcc-patches wrote: >> [PATCH, rs6000] Clean up the option_mask defines >> >> Hi, >> >> We have an assortment of MASK and OPTION_MASK #defines thro

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

Hi Haochen, on 2022/5/18 16:52, HAO CHEN GUI wrote: > Hi, > This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000. > Tests show that outputs of xs[min/max]dp are consistent with the standard > of C99 fmin/max. > > This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max

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

Hi Haochen, on 2022/5/26 15:35, HAO CHEN GUI wrote: > Hi, > This patch fixes the ICE reported in PR100736. It removes the condition > check of finite math only flag not setting in "*_cc" pattern. > With or without this flag, we still can use "cror" to check if either > two bits of CC is set or n

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

Hi Haochen, on 2022/5/31 09:52, HAO CHEN GUI wrote: > Hi, >This patch adds V1TI mode into a new mode iterator used in vector > comparison shift and rotation expands. Without the patch, the comparisons > between two vector __int128 are converted to scalar comparisons and > code is suboptimal. T

[PATCH] inline: Rebuild target option node for caller [PR105459]

Hi, PR105459 exposes one issue in inline_call handling that when it decides to copy FP flags from callee to caller and rebuild the optimization node for caller fndecl, it's possible that the target option node is also necessary to be rebuilt. Without updating target option node early, it can make

[PATCH] Update document for VECTOR_MODES_WITH_PREFIX

Hi, r10-3912 updated the format of VECTOR_MODES_WITH_PREFIX by adding one more parameter ORDER, the related document is out of date. So update the document for ORDER. Is it ok for trunk? BR, Kewen - gcc/ChangeLog: * machmode.def (VECTOR_MODES_WITH_PREFIX): Update document for

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

Hi Haochen, on 2022/6/6 10:21, HAO CHEN GUI wrote: > Hi, > This patch replaces shift and ior insns with one rotate and mask > insn for the split patterns which are for DI byte swap on Power6 and > before. The test cases shows the optimization. Nit: I noticed two splitting which are updated in t

PING^1 [PATCH] rs6000: Handle unresolved overloaded builtin [PR105485]

Hi, Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594699.html BR, Kewen on 2022/5/13 13:29, Kewen.Lin via Gcc-patches wrote: > Hi, > > PR105485 exposes that new builtin function framework doesn't handle > unresolved overloaded builtin function well.

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

Hi, Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595209.html BR, Kewen on 2022/5/18 22:07, Kewen.Lin via Gcc-patches wrote: > Hi, > > As PR104482 shown, it's one regression about the handlings when > the argument number is more than the one of built-in fun

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

Hi, Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595209.html BR, Kewen on 2022/5/18 22:07, Kewen.Lin via Gcc-patches wrote: > Hi, > > As PR103353 shows, we may want to continue to expand a MMA built-in > function like a normal function, even if we have already emi

Re: [PATCH,RS6000 2/5] Rework the RS6000_BTM defines.

Hi Will, The whole series looks good to me, thanks! IMHO one place can be further refactored, not sure if it's worth to updating together in this series, it's ... on 2022/6/7 06:05, will schmidt wrote: > [PATCH,RS6000 2/5) Rework the RS6000_BTM defines. > > The RS6000_BTM_ definitions are mostl

Re: [PATCH] Update document for VECTOR_MODES_WITH_PREFIX

on 2022/6/6 18:01, Richard Sandiford wrote: > "Kewen.Lin" writes: >> Hi, >> >> r10-3912 updated the format of VECTOR_MODES_WITH_PREFIX by >> adding one more parameter ORDER, the related document is out >> of date. So update the document for ORDER. >> >> Is it ok for trunk? >> >> BR, >> Kewen >> -

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

on 2022/6/8 11:28, HAO CHEN GUI wrote: > Hi, > This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000. > Tests show that outputs of xs[min/max]dp are consistent with the standard > of C99 fmin/max. > > This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead > of

[PATCH] vect: Move suggested_unroll_factor applying [PR105940]

Hi, As PR105940 shown, when rs6000 port tries to assign m_suggested_unroll_factor by 4 or so, there will be ICE on below statement: exact_div (LOOP_VINFO_VECT_FACTOR (loop_vinfo), loop_vinfo->suggested_unroll_factor); In function vect_analyze_loop_2, the current place of suggested

Re: [PATCH] vect: Move suggested_unroll_factor applying [PR105940]

on 2022/6/13 19:38, Richard Biener wrote: > On Mon, Jun 13, 2022 at 12:02 PM Kewen.Lin wrote: >> >> Hi, >> >> As PR105940 shown, when rs6000 port tries to assign >> m_suggested_unroll_factor by 4 or so, there will be ICE >> on below statement: >> >> exact_div (LOOP_VINFO_VECT_FACTOR (loop_vinfo)

[PATCH] predict: Adjust optimize_function_for_size_p [PR105818]

Hi, Function optimize_function_for_size_p returns OPTIMIZE_SIZE_NO if func->decl is not null but no cgraph node is available for it. As PR105818 shows, this could give unexpected result. For the case in PR105818, when parsing bar decl in function foo, the cfun is a function structure for foo, for

Re: [PATCH] predict: Adjust optimize_function_for_size_p [PR105818]

Hi Honza, Thanks for the comments! Some replies are inlined below. on 2022/6/14 19:37, Jan Hubicka wrote: >> Hi, >> >> Function optimize_function_for_size_p returns OPTIMIZE_SIZE_NO >> if func->decl is not null but no cgraph node is available for it. >> As PR105818 shows, this could give unexpec

Re: [PATCH] predict: Adjust optimize_function_for_size_p [PR105818]

on 2022/6/14 20:53, Segher Boessenkool wrote: > On Tue, Jun 14, 2022 at 03:57:08PM +0800, Kewen.Lin wrote: >> PR target/105818 > > Change this to something else? It is not a target bug. "middle-end" > perhaps? > Good catch, will fix this. Thanks Segher! BR, Kewen

<    4   5   6   7   8   9   10   11   >