[gomp4 simd, RFC] Simple fix to override vectorization cost estimation.

[Richard Biener]

Sergey Ostanevich <sergos.gnu@gmail.com> wrote:
>this is only for the whole file? I mean to have a particular loop
>vectorized in a
>file while all others - up to compiler's cost model. is there such a
>machinery?

No, there is not.

Richard.

>Sergos
>
>On Thu, Nov 14, 2013 at 12:39 PM, Richard Biener <rguenther@suse.de>
>wrote:
>> On Wed, 13 Nov 2013, Sergey Ostanevich wrote:
>>
>>> I will get some tests.
>>> As for cost analysis - simply consider the pragma as a request to
>>> vectorize. How can I - as a developer - enforce it beyond the
>pragma?
>>
>> You can disable the cost model via -fvect-cost-model=unlimited
>>
>> Richard.
>>
>>> On Wed, Nov 13, 2013 at 12:55 PM, Richard Biener <rguenther@suse.de>
>wrote:
>>> > On Tue, 12 Nov 2013, Sergey Ostanevich wrote:
>>> >
>>> >> 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'?
>>> >
>>> > For example.  I think we should report non-vectorized loops
>>> > that are marked with force_vect anyway, with
>-Wdisabled-optimization.
>>> > Another case is that a loop may be profitable to vectorize if
>>> > the ISA supports a gather instruction but otherwise not.  Or if
>the
>>> > ISA supports efficient vector construction from N not loop
>>> > invariant scalars (for vectorization of strided loads).
>>> >
>>> > Simply disregarding all of the cost analysis sounds completely
>>> > bogus to me.
>>> >
>>> > I'd simply go for the diagnostic for now, not changing anything
>else.
>>> > We want to have a good understanding about why the cost model is
>>> > so bad that we have to force to ignore it for #pragma simd - thus
>we
>>> > want testcases.
>>> >
>>> > Richard.
>>> >
>>> >>
>>> >> On Tue, Nov 12, 2013 at 6:35 PM, Richard Biener
><rguenther@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  <jakub@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
>>> >> >>
>>> >> >
>>> >>
>>> >>
>>> >
>>> > --
>>> > Richard Biener <rguenther@suse.de>
>>> > SUSE / SUSE Labs
>>> > SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
>>> > GF: Jeff Hawn, Jennifer Guild, Felix Imend
>>>
>>>
>>
>> --
>> Richard Biener <rguenther@suse.de>
>> SUSE / SUSE Labs
>> SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
>> GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer