On Fri, Nov 15, 2013 at 06:06:24PM +0400, Sergey Ostanevich wrote:
> here's an example that causes trigger for the cost model. As soon as
> elemental functions will appear and we update the vectorizer so it can accept
> an elemental function inside the loop - we will have the same
> situation as we have
> it now: cost model will bail out with profitability estimation.
Well, right now in the pending elemental patches there is no cost adjustment
in vectorize_simd_clone_call, which is wrong, because that effectively means
a call to the simd clone is considered as zero cost. Perhaps using
the scalar cost of the call (which is considered just as one instruction
anyway), plus perhaps some bigger overhead for argument setup if needed
would be what should we use. But of course we don't know the exact cost of
the scalar version of the function, nor vectorized one, and especially if it
is not in the current TU, we really can't know it.
I wonder if we shouldn't introduce
-fsimd-vect-cost-model=
where user could override the vect cost model for force_vect loops to
something else, be it -fsimd-vect-cost-model=unlimited to get what you are
asking, #pragma omp simd disregarding the cost model always, or
-fsimd-vect-cost-model=dynamic -fvect-cost-model=cheap etc.
Jakub
