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 &

Re: testsuite: Adjust pr96789.c to exclude vect_load_lanes

Hi Richard, Thanks for the review! on 2020/11/10 下午7:31, Richard Sandiford wrote: > "Kewen.Lin" writes: >> Hi, >> >> As Lyon pointed out, the newly introduced test case >> gcc.dg/tree-ssa/pr96789.c fails on arm-none-linux-gnueabihf. >> Loop vectoriz

testsuite: Adjust pr96789.c to exclude vect_load_lanes

Hi, As Lyon pointed out, the newly introduced test case gcc.dg/tree-ssa/pr96789.c fails on arm-none-linux-gnueabihf. Loop vectorizer is able to vectorize the two loops which operate on array tmp with load_lanes feature support. It makes dse3 get unexpected inputs and do nothing. This patch is

Re: [PATCH]ira: recompute regstat as max_regno changes [PR97705]

Hi Vladimir, on 2020/11/6 下午10:49, Vladimir Makarov wrote: > > On 2020-11-06 1:15 a.m., Kewen.Lin wrote: >> Hi, >> >> As PR97705 shows, my commit r11-4637 caused some dumping >> comparison difference error on pass ira.  It exposed one >> issue about the newly

[PATCH]ira: recompute regstat as max_regno changes [PR97705]

Hi, As PR97705 shows, my commit r11-4637 caused some dumping comparison difference error on pass ira. It exposed one issue about the newly introduced function remove_scratches, which can increase the largest pseudo reg number if it succeeds, later some function will use the max_reg_num() to get

Re: [PATCH v3] rs6000: Use direct move for char/short vector CTOR [PR96933]

Hi Segher, Thanks for the review! >>> Why does this test has_arch_pwr9 instead of adding -mdejagnu-cpu=power9? >> >> I thought using -mdejagnu-cpu=power9 would force the case run with >> power9 cpu all the time, while using has_arch_pwr9 seems to be more >> flexible, it can be compiled with

Re: [PATCH v3] pass: Run cleanup passes before SLP [PR96789]

Hi Lyon, Thanks for reporting and sorry for the failure. >> The patch was updated as your comments above, re-tested on Power8 >> and committed in r11-4637. >> > > The new test gcc.dg/tree-ssa/pr96789.c fails on arm: > FAIL: gcc.dg/tree-ssa/pr96789.c scan-tree-dump dse3 "Deleted dead

[PATCH v3] rs6000: Use direct move for char/short vector CTOR [PR96933]

Hi David, Thanks for the review! > The patch looks fine to me, but I'll let Segher decide if it addresses > his requested changes. > > I'm trying to be stricter about the test cases. > > +++ b/gcc/testsuite/gcc.target/powerpc/pr96933-1.c > @@ -0,0 +1,14 @@ > +/* { dg-do compile { target { lp64

Re: [PATCH v3] pass: Run cleanup passes before SLP [PR96789]

Hi Richard, Thanks again for your review! on 2020/11/2 下午6:23, Richard Sandiford wrote: > "Kewen.Lin" writes: >> diff --git a/gcc/function.c b/gcc/function.c >> index 2c8fa217f1f..3e92ee9c665 100644 >> --- a/gcc/function.c >> +++ b

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

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

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

Hi, Gentle ping for the patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553555.html BR, Kewen on 2020/10/13 下午2:59, Kewen.Lin via Gcc-patches wrote: > Hi, > > I'd like to gentle ping this patch: > > https://gcc.gnu.org/pipermail/gcc-patches/2020-Septem

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

Hi Richard, Thanks a lot for the review and sorry for the late reply. As the review comments, the changes against v2 are: - Fix the introduced tabification issues in passes.def. - Add pending TODOs group (different bitmask numbering). - Move pending_TODOs unsigned to struct function. -

[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

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

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

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

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

Hi Richard, Thanks for the comments! > diff --git a/gcc/tree-ssa-loop-ivcanon.c b/gcc/tree-ssa-loop-ivcanon.c > index 298ab215530..7016f993339 100644 > --- a/gcc/tree-ssa-loop-ivcanon.c > +++ b/gcc/tree-ssa-loop-ivcanon.c > @@ -1605,6 +1605,14 @@ pass_complete_unroll::execute (function *fun) >

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

Hi, As the discussion in PR96789, we found that some scalar stmts which can be eliminated by some passes after SLP, but we still modeled their costs when trying to SLP, it could impact vectorizer's decision. One typical case is the case in PR on target Power. As Richard suggested there, this

Re: [PATCH] vect: Fix epilogue loop handling of partial vectors

on 2020/9/23 下午7:33, Richard Sandiford wrote: > "Kewen.Lin" writes: >> on 2020/9/22 下午10:34, Richard Sandiford wrote: >>> Also, while splitting out the logic that handles epilogues with >>> constant iterations, I added a check to make sure that we don't >&g

Re: [PATCH] vect: Fix epilogue loop handling of partial vectors

Hi Richard, on 2020/9/22 下午10:34, Richard Sandiford wrote: > Richard Sandiford writes: >> I'll try to have a patch ready tomorrow morning European time. > > Well, I totally failed to hit that deadline. When testing on Power, > I saw a couple of extra failures, but I now think they're

Re: [PATCH] vect/test: Don't check for epilogue loop [PR97075]

Hi Richard, on 2020/9/21 下午2:50, Richard Sandiford wrote: > "Kewen.Lin" writes: >> Hi Richard, >>> "Kewen.Lin" writes: >>>> Hi, >>>> >>>> The commit r11-3230 brings a nice improvement to use full >>>> vectors

Re: [PATCH] vect/test: Don't check for epilogue loop [PR97075]

Hi Richard, > "Kewen.Lin" writes: >> Hi, >> >> The commit r11-3230 brings a nice improvement to use full >> vectors instead of partial vectors when available. But >> it caused some vector with length test cases to fail on >> Power. >> >

[PATCH] vect/test: Don't check for epilogue loop [PR97075]

Hi, The commit r11-3230 brings a nice improvement to use full vectors instead of partial vectors when available. But it caused some vector with length test cases to fail on Power. The failure on gcc.target/powerpc/p9-vec-length-epil-7.c exposed one issue that: we call function

Re: [PATCH v2] rs6000: Remove useless insns fed into lvx/stvx [PR97019]

Hi Segher, Thanks for your suggestions! >> + for (unsigned i = 0; i < and_insns.length (); ++i) > > "i++" is used more often, is more traditional. > Updated. >> --- /dev/null >> +++ b/gcc/testsuite/gcc.target/powerpc/pr97019.c >> @@ -0,0 +1,82 @@ >> +/* This issue can only exist on

PING^2 [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/8/31 下午1:49, Kewen.Lin via Gcc-patches wrote: > Hi, > > I'd like to gentle ping this since IVOPTs part is already to land. > > https://gcc.gnu.org/pipermail/gcc-patches/2020-

Re: [PATCH 3/4 v3] ivopts: Consider cost_step on different forms during unrolling

Hi Hans, on 2020/9/6 上午10:47, Hans-Peter Nilsson wrote: > On Tue, 1 Sep 2020, Bin.Cheng via Gcc-patches wrote: >>> Great idea! With explicitly specified -funroll-loops, it's bootstrapped >>> but the regression testing did show one failure (the only one): >>> >>> PASS->FAIL: gcc.dg/sms-4.c

[PATCH v2] rs6000: Remove useless insns fed into lvx/stvx [PR97019]

Hi Segher, Thanks for the review! >> * config/rs6000/rs6000-p8swap.c (insn_rtx_pair_t): New type. > > Please don't do that. The "first" and "second" are completely > meaningless. Also, keeping it separate arrays can very well result in > better machine code, and certainly makes easier

[PATCH]rs6000: Remove useless insns fed into lvx/stvx [PR97019]

Hi, This patch is to extend the existing function find_alignment_op to check all defintions of base_reg are AND operations with mask -16B to force the alignment. If all are satifised, it passes all AND operations and instructions in one vector to recombine_lvx_pattern and recombine_stvx_pattern,

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

Hi, As Segher's suggestion in the PR, for 128bit_direct_move, this new version leverages vector pack insns instead of vector perms with one control vector. The performance evaluation shows that it's on par with the previous version for char, while it's better than the previous for short.

[PATCH] rs6000: Use direct move for char/short vector CTOR [PR96933]

Hi, This patch is to make vector CTOR with char/short leverage direct move instructions when they are available. With one constructed test case, it can speed up 145% for char and 190% for short on P9. Tested SPEC2017 x264_r at -Ofast on P9, it gets 1.61% speedup (but based on unexpected SLP see

Re: [PATCH 3/4 v3] ivopts: Consider cost_step on different forms during unrolling

Hi Segher, on 2020/9/4 下午10:16, Segher Boessenkool wrote: > Hi! > > On Fri, Sep 04, 2020 at 04:47:37PM +0800, Kewen.Lin wrote: >>>> Apart from that, one P9 specific point is that the update form load isn't >>>> preferred, the reason is that the instruction can

Re: [PATCH] vec: remove unreachable code

Hi Andrea, on 2020/9/4 下午8:11, Andrea Corallo wrote: > Hi all, > > just a small patch removing a piece of unreachable code in > 'vect_estimate_min_profitable_iters' given the condition > (LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo)) is always true as > checked just above. > FWIW, I had

Re: [PATCH 3/4 v3] ivopts: Consider cost_step on different forms during unrolling

Hi Segher, >> Good question! I agree that they can execute in parallel, but it depends >> on how we interprete the addressing cost, if it's for required execution >> resource, I think it's off, since comparing with ld, the ldu has two iops >> and extra ALU requirement. > > OTOH, if you do not

Re: [PATCH 3/4 v3] ivopts: Consider cost_step on different forms during unrolling

Hi Segher, on 2020/9/2 下午6:25, Segher Boessenkool wrote: > Hi! > > On Wed, Sep 02, 2020 at 11:16:00AM +0800, Kewen.Lin wrote: >> on 2020/9/1 上午3:41, Segher Boessenkool wrote: >>> On Tue, Aug 25, 2020 at 08:46:55PM +0800, Kewen.Lin wrote: >>>> 1) Currentl

Re: [PATCH 3/4 v3] ivopts: Consider cost_step on different forms during unrolling

Hi Bin, I've updated the patch to punt ainc_use candidates as below: > + /* Skip AINC candidate since it contains address update itself, > +the replicated AINC computations when unrolling still have > +updates, unlike reg_offset_p candidates

Re: [PATCH 3/4 v3] ivopts: Consider cost_step on different forms during unrolling

Hi Bin, >> 2) This case makes me think we should exclude ainc candidates in function >> mark_reg_offset_candidates. The justification is that: ainc candidate >> handles step update itself and when we calculate the cost for it against >> its ainc_use, the cost_step has been reduced. When

Re: [PATCH 3/4 v3] ivopts: Consider cost_step on different forms during unrolling

Hi Segher, on 2020/9/1 上午3:41, Segher Boessenkool wrote: > Hi! > > Just a note: > > On Tue, Aug 25, 2020 at 08:46:55PM +0800, Kewen.Lin wrote: >> 1) Currently address_cost hook on rs6000 always return zero, but at least >> from Power7, pre_inc/pre_dec kind instructio

[PATCH] test/rs6000: Replace test target p8 and p9+

Hi, This is a trivial patch to clean existing rs6000 test targets p8 and p9+ with existing has_arch_pwr8 and has_arch_pwr9 target combination or only one of them. Not sure if it's a good idea to tidy this, but send out for comments. Bootstrapped/regtested on powerpc64le-linux-gnu P9. Any

Re: [PATCH] test/rs6000: Add Power9 and up as vect_len target

Hi Segher, >> proc check_effective_target_vect_len_load_store { } { >> -return 0 >> +return [expr { [check_effective_target_has_arch_pwr9] }] >> } > > Why not just > > return check_effective_target_has_arch_pwr9; > > ? (Or lose at least two pairs of brackets if not all three :-) )

Re: [PATCH] test/rs6000: Add Power9 and up as vect_len target

Hi Will, Thanks for the review! on 2020/9/1 上午1:13, will schmidt wrote: > On Mon, 2020-08-31 at 14:43 +0800, Kewen.Lin via Gcc-patches wrote: >> Hi, >> >> Power9 supports vector with length in bytes load/store, this patch >> is to teach check_effective_target_

[PATCH] test/rs6000: Add Power9 and up as vect_len target

Hi, Power9 supports vector with length in bytes load/store, this patch is to teach check_effective_target_vect_len_load_store to take it and its laters as effective vector with length targets. Also supplement the documents for has_arch_pwr*. Bootstrapped/regtested on powerpc64le-linux-gnu P8.

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

Hi, I'd like to gentle ping this since IVOPTs part is already to land. https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546698.html BR, Kewen on 2020/5/28 下午8:19, Kewen.Lin via Gcc-patches wrote: > > gcc/ChangeLog > > 2020-MM-DD Kewen Lin > > * cfgloop.h (struc

Re: [PATCH v2] testsuite: Update some vect cases for partial vectors

Hi Richard, > >> +# Return true if loops using partial vectors are supported but only for >> loops >> +# whose need to iterate can be removed, that is, value of >> +# param_vect_partial_vector_usage is set to 1. > > For these comments, I think it would be good to use the sourcebuild.texi >

[PATCH,GCC9]rs6000: Backport fixes for PR92923 and PR93136

Hi, This patch is to backport the fix for PR92923 and its sequent fix for PR93136 to GCC-9 branch. We found the builtin functions needlessly using VIEW_CONVERT_EXPRs on their operands can probably cause remarkable performance issue especailly when they are in the hotspot. One typical case is

[PATCH 3/4 v3] ivopts: Consider cost_step on different forms during unrolling

Hi Bin, >> >> For one particular case like: >> >> for (i = 0; i < SIZE; i++) >> y[i] = a * x[i] + z[i]; >> >> we will mark reg_offset_p for IV candidates on x as below: >>- (unsigned long) (x_18(D) + 8)// only mark this before. >>- x_18(D) + 8 >>-

[PATCH v2] testsuite: Update some vect cases for partial vectors

Hi Richard, >> Yeah, the comments were confusing, its intent is to check which targets >> support partial vectors and which usage to be used. >> >> How about to update them like: >> >> "Return true if loops using partial vectors are supported and usage kind is >> 1/2". > > I wasn't really

[PATCH v2] options: Make --help= to emit values post-overrided

Hi Segher, on 2020/8/15 上午6:01, Segher Boessenkool wrote: > Hi! > > On Fri, Aug 14, 2020 at 01:42:24PM +0800, Kewen.Lin wrote: >>> I think personally I'd prefer an option (3): call >>> target_option_override_hook directly in decode_options, >>> if help_option_

[PATCH 3/4 v2] ivopts: Consider cost_step on different forms during unrolling

Hi Bin, > I see, it's similar to the auto-increment case where cost should be > recorded only once. So this is okay given 1) fine predicting > rtl-unroll is likely impossible here; 2) the patch has very limited > impact. > Really appreciate your time and patience! I extended the previous

Re: [PATCH] options: Make --help= to emit values post-overrided

Hi Richard, Thanks for the comments! on 2020/8/13 上午12:10, Richard Sandiford wrote: > "Kewen.Lin" writes: >> Hi Segher, >> >> on 2020/8/7 锟斤拷锟斤拷10:42, Segher Boessenkool wrote: >>> Hi! >>> >>> On Fri, Aug 07, 2020 at 10:44:10AM +0800

[PATCH] testsuite: Add -fno-common to pr82374.c [PR94077]

Hi, As the PR comments show, the case gcc.dg/gomp/pr82374.c fails on Power7 since gcc8. But it passes from gcc10. By looking into the difference, it's due to that gcc10 sets -fno-common as default, which makes vectorizer force the alignment and be able to use aligned vector load/store on those

Re: [PATCH 3/4] ivopts: Consider cost_step on different forms during unrolling

Hi Bin, on 2020/8/10 下午8:38, Bin.Cheng wrote: > On Mon, Aug 10, 2020 at 12:27 PM Kewen.Lin wrote: >> >> Hi Bin, >> >> Thanks for the review!! >> >> on 2020/8/8 下午4:01, Bin.Cheng wrote: >>> Hi Kewen, >>> Sorry for the late reply. >&g

[PATCH] options: Make --help= to emit values post-overrided

Hi Segher, on 2020/8/7 下午10:42, Segher Boessenkool wrote: > Hi! > > On Fri, Aug 07, 2020 at 10:44:10AM +0800, Kewen.Lin wrote: >>> I think this makes a lot of sense. >>> >>>> btw, not sure whether it's a good idea to move target_option_override_hook >>

Re: [PATCH 3/4] ivopts: Consider cost_step on different forms during unrolling

Hi Bin, Thanks for the review!! on 2020/8/8 下午4:01, Bin.Cheng wrote: > Hi Kewen, > Sorry for the late reply. > The patch's most important change is below cost computation: > >> @@ -5890,6 +5973,10 @@ determine_iv_cost (struct ivopts_data *data, struct >> iv_cand *cand) >> cost_step =

Re: [PATCH/RFC] options: Make --help= to emit values post-overrided

Hi Segher! Thanks for the comments! on 2020/8/7 上午6:04, Segher Boessenkool wrote: > Hi! > > On Thu, Aug 06, 2020 at 08:37:23PM +0800, Kewen.Lin wrote: >> When I was working to update patch as Richard's review comments >> here https://gcc.gnu.org/pipermail/gcc-patches/20

[PATCH/RFC] options: Make --help= to emit values post-overrided

Hi, When I was working to update patch as Richard's review comments here https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551474.html， I noticed that the options "-Q --help=params" don't show the final values after target option overriding, instead it emits the default values in params.opt

Re: [PATCH] testsuite: Update some vect cases for partial vectors

Hi Richard, Thanks for the review! on 2020/8/6 下午1:52, Richard Sandiford wrote: > "Kewen.Lin" writes: >> diff --git a/gcc/testsuite/gcc.dg/vect/slp-multitypes-11.c >> b/gcc/testsuite/gcc.dg/vect/slp-multitypes-11.c >> index 5200ed1cd94..da6fb12eb0d 100644 >>

Re: [PATCH v5] vect/rs6000: Support vector with length cost modeling

on 2020/8/5 下午10:06, Segher Boessenkool wrote: > On Wed, Aug 05, 2020 at 08:27:57AM +0100, Richard Sandiford wrote: >> OK for the vectoriser parts with those changes, thanks. > > The rs6000 part is still fine as well. Thanks! > > Committed via r11-2586. Thanks all! BR, Kewen

[PATCH] testsuite: Update some vect cases for partial vectors

Hi, This patch is to adjust some existing vectorization test cases to stay well with the newly introduced partial vector usages. Bootstrapped/regtested on aarch64-linux-gnu and powerpc64le-linux-gnu P9 (with explicit param vect-partial-vector-usage=1 and enablement on

[PATCH] vect: Skip epilogue loops for dbgcnt check [PR96451]

Hi, As the PR shows, commit r11-2453 exposed one issue that vectorizer wants to vectorize the epilogue loop and leaves the if-cvt body there, but later dbgcnt check disables it, the left scalar mask_store statement cause ICE. As Richard pointed out in that PR, the dbgcnt is to count original

[PATCH v5] vect/rs6000: Support vector with length cost modeling

Hi Richard, New version v5 is attached. v5 main changes against v4: 1) use _stmt instead of _cnt to avoid confusion 2) factor out function vect_rgroup_iv_might_wrap_p 3) use generic scalar_stmt for min/max stmt Does this look better? Thanks in advance! BR, Kewen - gcc/ChangeLog:

Re: Refactor peel_iters_{pro,epi}logue cost model handlings

on 2020/7/31 下午6:57, Richard Sandiford wrote: > "Kewen.Lin" writes: >> Hi Richard, >> >> on 2020/7/27 下午9:10, Richard Sandiford wrote: >>> "Kewen.Lin" writes: >>>> Hi, >>>> >>>> As Richard S. suggested in

Re: [PATCH v4] vect/rs6000: Support vector with length cost modeling

on 2020/7/31 下午9:01, Richard Biener wrote: > On Fri, Jul 31, 2020 at 2:37 PM Kewen.Lin wrote: >> >> Hi Richards, >> >> on 2020/7/31 下午7:20, Richard Biener wrote: >>> On Fri, Jul 31, 2020 at 1:03 PM Richard Sandiford >>> wrote: >>>> >

Re: [PATCH v4] vect/rs6000: Support vector with length cost modeling

Hi Richards, on 2020/7/31 下午7:20, Richard Biener wrote: > On Fri, Jul 31, 2020 at 1:03 PM Richard Sandiford > wrote: >> >> "Kewen.Lin" writes: >>>>> + bool niters_known_p = LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo); >>>>> +

Re: [PATCH, rs6000] Add non-relative jump table support for 64bit rs6000

Added more CCs. Kewen on 2020/7/28 下午1:25, HAO CHEN GUI via Gcc-patches wrote: > Hi, > > This patch adds non-relative jump table support for 64bit rs6000. It > implements ASM_OUTPUT_ADDR_VEC_ELT and corresponding expansion of jump table > instruction for 64bit rs6000. We want to put

Re: [PATCH v4] vect/rs6000: Support vector with length cost modeling

Hi Richard, Thanks for the comments! on 2020/7/27 下午9:40, Richard Sandiford wrote: > "Kewen.Lin" writes: [snip] >> + bool niters_known_p = LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo); >> + bool need_iterate_p >> += (!LO

Re: Refactor peel_iters_{pro,epi}logue cost model handlings

Hi Richard, on 2020/7/27 下午9:10, Richard Sandiford wrote: > "Kewen.Lin" writes: >> Hi, >> >> As Richard S. suggested in the thread: >> >> https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550633.html >> >> this patch is separated from the

[PATCH v4] vect/rs6000: Support vector with length cost modeling

Hi Richard, Thanks for the review again! on 2020/7/25 上午12:21, Richard Sandiford wrote: > "Kewen.Lin" writes: > > Thanks, the rearrangement of the existing code looks good. Could you > split that and the new LOOP_VINFO_FULLY_WITH_LENGTH_P (loop_vinfo) stuff >

Re: [PATCH v2] vect/rs6000: Support vector with length cost modeling

Hi Segher, Thanks for the comments! on 2020/7/23 上午1:49, Segher Boessenkool wrote: > Hi! > > On Wed, Jul 22, 2020 at 09:26:39AM +0800, Kewen.Lin wrote: >> +/* For some target specific vectorization cost which can't be handled per >> stmt, >> + we check the requ

Refactor peel_iters_{pro,epi}logue cost model handlings

Hi, As Richard S. suggested in the thread: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550633.html this patch is separated from the one of that thread, mainly to refactor the existing peel_iters_{pro,epi}logue cost model handlings. I've addressed Richard S.'s review comments there,

Re: [PATCH v3] vect/rs6000: Support vector with length cost modeling

Hi, Sorry, please ignore the previously attached file, which isn't the latest one although almost are the same. The latest tested is attached here. Sorry for the inconvenience. BR, Kewen on 2020/7/22 下午11:48, Kewen.Lin via Gcc-patches wrote: > > It's a great idea, by followin

Re: [PATCH] rs6000: Rename adjust_vectorization_cost

Hi Segher, on 2020/7/22 下午4:26, Segher Boessenkool wrote: > Hi! > > On Wed, Jul 22, 2020 at 09:44:52AM +0800, Kewen.Lin wrote: >> This trivial patch is to rename adjust_vectorization_cost to >> adjust_vect_cost_per_stmt. Hope it's more meaningful, as well >> as to

[PATCH v3] vect/rs6000: Support vector with length cost modeling

Hi Richard, Thanks for the review! on 2020/7/22 下午5:11, Richard Sandiford wrote: > "Kewen.Lin" writes: >> - else if (LOOP_VINFO_FULLY_WITH_LENGTH_P (loop_vinfo)) >> -{ >> - peel_iters_prologue = 0; >> - peel_iters_epilogue = 0; >> +

Re: [PATCH v2] vect/rs6000: Support vector with length cost modeling

Hi Richard, on 2020/7/22 下午2:38, Richard Biener wrote: > On Wed, Jul 22, 2020 at 3:26 AM Kewen.Lin wrote: >> >> Hi Richard, >> >> on 2020/7/21 下午3:57, Richard Biener wrote: >>> On Tue, Jul 21, 2020 at 7:52 AM Kewen.Lin wrote: >>>> >>&

[PATCH] rs6000: Rename adjust_vectorization_cost

Hi, This trivial patch is to rename adjust_vectorization_cost to adjust_vect_cost_per_stmt. Hope it's more meaningful, as well as to avoid the confusion between the possible to be landed function "adjust_vect_cost" and "adjust_vectorization_cost". Even without "adjust_vect_cost", I guess it's

[PATCH v2] vect/rs6000: Support vector with length cost modeling

Hi Richard, on 2020/7/21 下午3:57, Richard Biener wrote: > On Tue, Jul 21, 2020 at 7:52 AM Kewen.Lin wrote: >> >> Hi, >> >> This patch is to add the cost modeling for vector with length, >> it mainly follows what we generate for vector with length in >> fu

[PATCH] vect: Support vector with length cost modeling

Hi, This patch is to add the cost modeling for vector with length, it mainly follows what we generate for vector with length in functions vect_set_loop_controls_directly and vect_gen_len at the worst case. For Power, the length is expected to be in bits 0-7 (high bits), we have to model the cost

Re: [PATCH 7/7 v2] rs6000/testsuite: Vector with length test cases

Hi Segher, on 2020/7/21 上午12:58, Segher Boessenkool wrote: > Hi! > > On Fri, Jul 10, 2020 at 06:07:16PM +0800, Kewen.Lin wrote: >> +/* { dg-do compile { target { powerpc*-*-* } && { lp64 && >> powerpc_p9vector_ok } } } */ > > Everyth

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

Hi Richard, on 2020/7/17 下午5:54, Richard Sandiford wrote: > Hi, > > Sorry for the slow review. > >> The new version v7 is attached which has addressed your review comments >> on v6. Could you have a further look? Many thanks in advance! >> >> Bootstrapped/regtested on aarch64-linux-gnu and

Re: [PATCH] testsuite/rs6000: Add option to ignore vect cost model

Hi, on 2020/7/17 上午4:31, Segher Boessenkool wrote: > Hi! > > On Thu, Jul 16, 2020 at 02:51:23PM +0800, Kewen.Lin wrote: >> In my testing with cost tweaking for vector with length, I found >> two cases below didn't get the expected output. Since the expected

[PATCH] testsuite/rs6000: Add option to ignore vect cost model

Hi, In my testing with cost tweaking for vector with length, I found two cases below didn't get the expected output. Since the expected instructions reply on the vectorization occurrence, we don't expect vectorization gets disabled by cost model. To make it not fragile, the fix is to force it

Re: [PATCH] remove premature vect_verify_datarefs_alignment

on 2020/7/9 下午7:22, Richard Biener wrote: > On Thu, 9 Jul 2020, Kewen.Lin wrote: > >> on 2020/7/9 上午10:48, Kewen.Lin via Gcc-patches wrote: >>> Hi Richi, >>> >>> on 2020/7/8 下午10:45, Richard Biener wrote: >>>> This followup removes ve

[PATCH 7/7 v2] rs6000/testsuite: Vector with length test cases

Hi, v2 changes: - Updated param from vect-with-length-scope to vect-partial-vector-usage - Add *-7*/*-8* to cover peeling alignment and gaps. All cases passed on powerpc64le-linux-gnu P9. BR, Kewen - gcc/testsuite/ChangeLog: * gcc.target/powerpc/p9-vec-length-1.h: New

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

Hi Richard, The new version v7 is attached which has addressed your review comments on v6. Could you have a further look? Many thanks in advance! Bootstrapped/regtested on aarch64-linux-gnu and powerpc64le-linux-gnu P9. Even with explicit vect-partial-vector-usage settings 1/2 on Power target,

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

Hi Richard, on 2020/7/8 下午8:50, Richard Sandiford wrote: > "Kewen.Lin" writes: >>> […] >>>> I tested the updated patch with this releasing, LOOP_VINFO_PEELING_FOR_GAPS >>>> part looks fine, but LOOP_VINFO_PEELING_FOR_ALIGNMENT caused one case to >

Re: [PATCH] remove premature vect_verify_datarefs_alignment

on 2020/7/9 上午10:48, Kewen.Lin via Gcc-patches wrote: > Hi Richi, > > on 2020/7/8 下午10:45, Richard Biener wrote: >> This followup removes vect_verify_datarefs_alignment and its >> premature cancellation of vectorization leaving the actual >> decision whe

Re: [PATCH] remove premature vect_verify_datarefs_alignment

Hi Richi, on 2020/7/8 下午10:45, Richard Biener wrote: > This followup removes vect_verify_datarefs_alignment and its > premature cancellation of vectorization leaving the actual > decision whether alignment is supported to the functions > deciding whether we can vectorize a load or store. > >

[PATCH] vect: Enhance condition check to use partial vectors in vectorizable_condition

Hi, This patch is derived from the review of vector with length patch series. The length-based partial vector approach doesn't support reduction so far, so we would like to disable vectorization with partial vectors explicitly for it in vectorizable_condition. Otherwise, it will cause some

[PATCH] vect/testsuite: Adjust dumping for fully masking decision

Hi, As Richard S. suggested in the review of vector with length patch series, we can use one message on "partial vectors" instead of "fully with masking". This patch is to update the dumping string and related test cases. Bootstrapped/regtested on aarch64-linux-gnu. Is it ok for trunk? BR,

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

Hi Richard, on 2020/7/7 下午6:15, Richard Sandiford wrote: > "Kewen.Lin" writes: >> Hi Richard, >> >> on 2020/7/1 下午11:17, Richard Sandiford wrote: >>> "Kewen.Lin" writes: >>>> on 2020/7/1 上午3:53, Richard Sandiford wrote: >

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

Hi Richard, on 2020/7/7 下午6:44, Richard Sandiford wrote: > "Kewen.Lin" writes: >> on 2020/7/2 下午1:20, Kewen.Lin via Gcc-patches wrote: >>> on 2020/7/1 下午11:17, Richard Sandiford wrote: >>>> "Kewen.Lin" writes: >>>>> on 202

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

Hi Richard, on 2020/7/2 下午1:20, Kewen.Lin via Gcc-patches wrote: > on 2020/7/1 下午11:17, Richard Sandiford wrote: >> "Kewen.Lin" writes: >>> on 2020/7/1 上午3:53, Richard Sandiford wrote: >>>> "Kewen.Lin" writes: [...] >> Hmm, OK. Bu

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); >>>> +

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

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

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

[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

[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

[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

[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

[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

<    7   8   9   10   11   12   13   14   15   >