Richard, Jakub, You are right regarding the cost model if we talk about vectorizer alone. But the #pragma omp simd goes beyond the vectorizer - it introduces parallel context in a place user defines, similar to #pragma omp parallel. Are we applying any cost model for omp parallel region?
You can consider this pragma as a helper for developer for 'easily' introduce parallelism in his code, hence any type of cost model - whatever quality it is - will plays against this paradigm, forcing user to play around our cost model to let it make the loop simd-parallel. Sergos On Thu, Oct 31, 2013 at 10:36 PM, Richard Biener <rguent...@suse.de> wrote: > Jakub Jelinek <ja...@redhat.com> wrote: >>On Thu, Oct 31, 2013 at 07:02:28PM +0400, Yuri Rumyantsev wrote: >>> Here is a simple fix which allows to vectorize loop marked with >>> 'pragma omp simd' even if cost model tells us that vectorization is >>> not profitable. >>> I checked that on simple test-case is works as expected. >>> >>> Is it Ok for trunk? >>> >>> ChangeLog: >>> >>> 2013-10-31 Yuri Rumyantsev <ysrum...@gmail.com> >>> >>> * tree-vect-loop.c (vect_estimate_min_profitable_iters): Override >>> cost estimation for loops marked as vectorizable. >> >>That looks too simplistics, IMHO it is undesirable to disregard the >>profitability checks together. For #pragma omp simd or #pragma simd >>loops, I can understand that we should admit our cost model is not very >>high >>quality and so in border cases consider vectorizing rather than not >>vectorizing, say for force_vect by increasing the scalar cost by some >>factor or decreasing vector cost by some factor, but disregarding it >>altogether doesn't look wise. The question is what factor should we >>use? >>150% of scalar cost, something else? > > Please improve the cost-model instead. > > Thanks, > Richard. > >> Jakub > >
