"Andre Vieira (lists)" writes:
> Made the suggested changes.
>
> Regarding the name change to partial vectors, I agree in the name change
> since that is the terminology we are using in the loop_vinfo members
> too, but is there an actual difference between predication/masking and
> partial vec
Made the suggested changes.
Regarding the name change to partial vectors, I agree in the name change
since that is the terminology we are using in the loop_vinfo members
too, but is there an actual difference between predication/masking and
partial vectors that I am missing?
OK for trunk?
g
"Andre Vieira (lists)" writes:
> Hi,
>
> Added an extra step to skip unusable epilogue modes when we know the
> target does not support predication. This uses a new function
> 'support_predication_p' that is generated at build time and checks
> whether the target supports at least one optab tha
Hi,
Added an extra step to skip unusable epilogue modes when we know the
target does not support predication. This uses a new function
'support_predication_p' that is generated at build time and checks
whether the target supports at least one optab that can be used for
predicated code-generat
On 07/12/2021 11:45, Richard Biener wrote:
Can you check whether, give we know the main VF, the epilogue analysis
does not start with am autodetected vector mode that needs a too large VF?
Hmm struggling to see how we could check this here. AFAIU before we
analyze the loop for a given vector
On Tue, 7 Dec 2021, Richard Sandiford wrote:
> Richard Biener writes:
> > On Tue, 7 Dec 2021, Andre Vieira (lists) wrote:
> >
> >> Hi,
> >>
> >> Rebased on top of the epilogue mode patch.
> >>
> >> OK for trunk?
> >
> > @@ -7242,7 +7315,8 @@ vectorizable_reduction (loop_vec_info loop_vinfo,
> >
Richard Biener writes:
> On Tue, 7 Dec 2021, Andre Vieira (lists) wrote:
>
>> Hi,
>>
>> Rebased on top of the epilogue mode patch.
>>
>> OK for trunk?
>
> @@ -7242,7 +7315,8 @@ vectorizable_reduction (loop_vec_info loop_vinfo,
> participating. */
>if (ncopies > 1
>&& (STMT_VINFO
On Tue, 7 Dec 2021, Andre Vieira (lists) wrote:
> Hi,
>
> I've split this particular part off, since it's not only relevant to
> unrolling. The new test shows how this is useful for existing (non-unrolling)
> cases. I also had to fix the costing function, the main_vf / epilogue_vf
> calculations
On Tue, 7 Dec 2021, Andre Vieira (lists) wrote:
> Hi,
>
> Rebased on top of the epilogue mode patch.
>
> OK for trunk?
@@ -7242,7 +7315,8 @@ vectorizable_reduction (loop_vec_info loop_vinfo,
participating. */
if (ncopies > 1
&& (STMT_VINFO_RELEVANT (stmt_info) <= vect_used_only_l
Hi,
Rebased on top of the epilogue mode patch.
OK for trunk?
gcc/ChangeLog:
* tree-vect-loop.c (vect_estimate_min_profitable_iters): Pass
new argument
suggested_unroll_factor.
(vect_analyze_loop_costing): Likewise.
(_loop_vec_info::_loop_vec_info): Initialize
Hi,
I've split this particular part off, since it's not only relevant to
unrolling. The new test shows how this is useful for existing
(non-unrolling) cases. I also had to fix the costing function, the
main_vf / epilogue_vf calculations for old and new didn't take into
consideration that the
11 matches
Mail list logo
