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 instructions are cracked, it means we
>
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 commen
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 :-) )
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_vec
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.
I
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 (
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
> word
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
h
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
>>- (unsigne
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 comment
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_arguments is nonempty. Like you say,
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 versio
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, Kewen.Lin wrote:
> I think this makes a lot of sense.
>>>
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 t
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.
>>> The patch's most important change is below cost computation:
>>>
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
call into print_specific_help and use one
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 = add_co
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/2020-August/551474.html，
>>
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 (w
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
>> --- a/gcc/testsuite/gcc.dg/vect/slp-
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
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
check_effective_target_vect_
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
scal
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:
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 the thread:
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550633.html
>
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:
"Kewen.Lin" writes:
>>> + bool niters_known_p = LO
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);
> + bool need_iterate_p
> + = (!LOOP_VINFO_EPILOGUE_P (loop_vin
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 non-relati
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
>> += (!LOOP_VINFO_EPILOGUE_P (loop_vinfo)
>> + && !vect_known_niters_
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 one of that thread, mainly to refactor the
>> existing p
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
> out into separate patches?
>
Spl
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 requisite conditions and adjust the
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, more
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, b
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 avoid the confusion between th
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;
>> + if (LOOP_VINFO_FULLY_MASKED_P (loop_vinfo))
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:
Hi,
This patch is to add the cost modeling for vec
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 s
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
>> functions vect_set_loop_controls_directly and
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
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 } } } */
>
> Everything in gcc.targer/powerpc/ requires powerpc*-*-* automatically
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 pow
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
>> instructions reply on the vectoriza
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 wi
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
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 test.
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,
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
fail at execution during vect-partial-vector-u
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 whether al
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.
>
> I'll
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 unexpe
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,
Kew
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:
> "Kewen.Lin" writes:
Sorry, I didn't quite follow this comme
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
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. But in t
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
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
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 +
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
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
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
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
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/
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
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
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
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.
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
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
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
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/
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 ==
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
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
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/
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.
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_
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
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
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
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
on 2020/6/3 下午5:27, Richard Biener wrote:
> On Wed, 3 Jun 2020, Kewen.Lin wrote:
>
>> on 2020/6/3 下午3:07, Richard Biener wrote:
>>> On Wed, 3 Jun 2020, Kewen.Lin wrote:
>>>
Hi Richi,
snip ...
>
> I'd just mention there are other targets that have the choice between
> the ab
on 2020/6/3 下午3:07, Richard Biener wrote:
> On Wed, 3 Jun 2020, Kewen.Lin wrote:
>
>> Hi Richi,
>>
>> on 2020/6/2 下午7:38, Richard Biener wrote:
>>> On Thu, 28 May 2020, Kewen.Lin wrote:
>>>
Hi,
This is one repost and you can refer to the original series
via https://gcc.gnu.org
Hi Richard,
Thanks a lot for your great comments!
on 2020/6/2 下午7:50, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> on 2020/5/29 下午4:32, Richard Sandiford wrote:
>>> "Kewen.Lin" writes:
on 2020/5/27 下午6:02, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi
Hi Richi,
on 2020/6/2 下午7:38, Richard Biener wrote:
> On Thu, 28 May 2020, Kewen.Lin wrote:
>
>> Hi,
>>
>> This is one repost and you can refer to the original series
>> via https://gcc.gnu.org/pipermail/gcc-patches/2020-January/538360.html.
>>
>> As we discussed in the thread
>> https://gcc.gnu
Hi Richard,
on 2020/6/2 下午3:14, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> Thanks for the comments!
>>
>> on 2020/6/2 上午1:59, Richard Sandiford wrote:
>>> Could you go into more detail about this choice of cost calculation?
>>> It looks like we first calculate per-group f
Hi Richard,
on 2020/5/29 下午4:32, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> on 2020/5/27 下午6:02, Richard Sandiford wrote:
>>> "Kewen.Lin" writes:
Hi Richard,
Snip ...
>>
>> Thanks a lot for your detailed explanation! This proposal looks good
>> based on the current implementa
Hi Richard,
Thanks for the comments!
on 2020/6/2 上午1:59, Richard Sandiford wrote:
> Could you go into more detail about this choice of cost calculation?
> It looks like we first calculate per-group flags, which are true only if
> the unrolled offsets are valid for all uses in the group. Then we
gcc/ChangeLog
2020-MM-DD Kewen Lin
* tree-ssa-loop-ivopts.c (struct iv_group): New field reg_offset_p.
(struct iv_cand): New field reg_offset_p.
(struct ivopts_data): New field consider_reg_offset_for_unroll_p.
(dump_groups): Dump group with reg_offset_p.
gcc/ChangeLog
2020-MM-DD Kewen Lin
* doc/invoke.texi (iv-consider-reg-offset-for-unroll): Document new
option.
* params.opt (iv-consider-reg-offset-for-unroll): New.
* config/s390/s390.c (s390_option_override_internal): Disable parameter
iv-consider-reg-offset
gcc/ChangeLog
2020-MM-DD Kewen Lin
* cfgloop.h (struct loop): New field estimated_unroll.
* tree-ssa-loop-manip.c (decide_unroll_const_iter): New function.
(decide_unroll_runtime_iter): Likewise.
(decide_unroll_stupid): Likewise.
(estimate_unroll_factor
Hi,
This is one repost and you can refer to the original series
via https://gcc.gnu.org/pipermail/gcc-patches/2020-January/538360.html.
As we discussed in the thread
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00196.html
Original: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00104.html,
I'm w
!
Kewen
on 2020/5/13 下午1:50, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> I'd like to ping this patch as well as its sblings. Thanks in advance.
>
> 1/4 v3 https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540171.html
> 2/4 v3 https://gcc.gnu.org/pipermail/gcc-patches/202
on 2020/5/27 下午6:02, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> Thanks for your comments!
>>
>> on 2020/5/26 锟斤拷锟斤拷8:49, Richard Sandiford wrote:
>>> "Kewen.Lin" writes:
@@ -626,6 +645,12 @@ public:
/* True if have decided to use a fully-masked loop. */
on 2020/5/27 下午3:25, Richard Biener wrote:
> On Tue, 26 May 2020, Segher Boessenkool wrote:
>
>> Hi!
>>
>> On Tue, May 26, 2020 at 01:29:30PM +0100, Richard Sandiford wrote:
>>> FWIW, I agree adding .LEN_LOAD and .LEN_STORE seems like a good
>>> approach. I think it'll be more maintainable in the
Hi Richard,
Thanks for your comments!
on 2020/5/26 下午8:49, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> @@ -626,6 +645,12 @@ public:
>>/* True if have decided to use a fully-masked loop. */
>>bool fully_masked_p;
>>
>> + /* Records whether we still have the option of using a len
on 2020/5/26 下午5:44, Richard Biener wrote:
> On Tue, 26 May 2020, Kewen.Lin wrote:
>
>> Hi Richi,
>>
>> on 2020/5/26 下午3:12, Richard Biener wrote:
>>> On Tue, 26 May 2020, Kewen.Lin wrote:
>>>
Hi all,
This patch set adds support for vector load/store with length, Power
ISA 3.0
Hi Richi,
on 2020/5/26 下午3:12, Richard Biener wrote:
> On Tue, 26 May 2020, Kewen.Lin wrote:
>
>> Hi all,
>>
>> This patch set adds support for vector load/store with length, Power
>> ISA 3.0 brings instructions lxvl/stxvl to perform vector load/store with
>> length, it's good to be exploited fo
gcc/testsuite/ChangeLog
2020-MM-DD Kewen Lin
* gcc.target/powerpc/p9-vec-length-1.h: New test.
* gcc.target/powerpc/p9-vec-length-2.h: New test.
* gcc.target/powerpc/p9-vec-length-3.h: New test.
* gcc.target/powerpc/p9-vec-length-4.h: New test.
* gcc.tar
gcc/ChangeLog
2020-MM-DD Kewen Lin
* tree-ssa-loop-ivopts.c (get_mem_type_for_internal_fn): Handle
IFN_LEN_LOAD and IFN_LEN_STORE.
(get_alias_ptr_type_for_ptr_address): Likewise.
---
gcc/tree-ssa-loop-ivopts.c | 4
1 file changed, 4 insertions(+)
diff --git a/g
901 - 1000 of 1024 matches
Mail list logo
