The reason patch was in its original state is because we want
to notify user that his assumption of profitability may be wrong.
This is not a part of any spec and as far as I know ICC does not
notify user about the case. Still it can be a good hint for those
users who tries to get as much as possible performance.
Richard's comment on the vectorization problems is about the same -
to inform user that his attempt to force vectorization is failed.
As for profitable or not - sometimes I believe it's impossible to be
precise. For OMP we have case of a vector version of a function
and we have no chance to figure out whether it is profitable to use
it or to loose it. If we can't map the loop for any vector length
other than 1 - I believe in this case we have to bail out and report.
Is it about 'never profitable'?
On Tue, Nov 12, 2013 at 6:35 PM, Richard Biener <rguent...@suse.de> wrote:
> On 11/12/13 3:16 PM, Jakub Jelinek wrote:
>> On Tue, Nov 12, 2013 at 05:46:14PM +0400, Sergey Ostanevich wrote:
>>> ivdep just substitutes all cross-iteration data analysis,
>>> nothing related to cost model. ICC does not cancel its
>>> cost model in case of #pragma ivdep
>>>
>>> as for the safelen - OMP standart treats it as a limitation
>>> for the vector length. this means if no safelen is present
>>> an arbitrary vector length can be used.
>>
>> I was talking about GCC loop->safelen, which is INT_MAX for #pragma omp simd
>> without safelen clause or #pragma simd without vectorlength clause.
>>
>>> so I believe loop->force_vect is the only trigger to disregard
>>> the cost model
>>
>> Anyway, in that case I think the originally posted patch is wrong,
>> if we want to treat force_vect as disregard all the cost model and
>> force vectorization (well, the name of the field already kind of suggest
>> that), then IMHO we should treat it the same as -fvect-cost-model=unlimited
>> for those loops.
>
> Err - the user may have a specific sub-architecture in mind when using
> #pragma simd, if you say we should completely ignore the cost model
> then should we also sorry () if we cannot vectorize the loop (either
> because of GCC deficiencies or lack of sub-target support)?
>
> That said, at least in the cases that the cost model says the loop
> is never profitable to vectorize we should follow its advice.
>
> Richard.
>
>> Thus (untested):
>>
>> 2013-11-12 Jakub Jelinek <ja...@redhat.com>
>>
>> * tree-vect-loop.c (vect_estimate_min_profitable_iters): Use
>> unlimited cost model also for force_vect loops.
>>
>> --- gcc/tree-vect-loop.c.jj 2013-11-12 12:09:40.000000000 +0100
>> +++ gcc/tree-vect-loop.c 2013-11-12 15:11:43.821404330 +0100
>> @@ -2702,7 +2702,7 @@ vect_estimate_min_profitable_iters (loop
>> void *target_cost_data = LOOP_VINFO_TARGET_COST_DATA (loop_vinfo);
>>
>> /* Cost model disabled. */
>> - if (unlimited_cost_model ())
>> + if (unlimited_cost_model () || LOOP_VINFO_LOOP (loop_vinfo)->force_vect)
>> {
>> dump_printf_loc (MSG_NOTE, vect_location, "cost model disabled.\n");
>> *ret_min_profitable_niters = 0;
>>
>> Jakub
>>
>
