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

[Richard Biener]

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