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

[Richard Biener <rguenther at suse dot de>]

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