--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #11)
> (In reply to rguent...@suse.de from comment #9)
> > I believe atom _does_ have full SSE2 support, no? Using intrinsics
> > (even those expanding to GCC generic vector extension code) should
> > end up emitting SSE2 double instructions?
> > So what you want to tell the vectorizer is to not introduce vectorized
> > code using V2DFmode. I still think a better way is to handle this
> > via costs (like a loop with mostly integer ops but a single FP double
> > op is probably still profitable to vectorize).
> The patch, attached in the previous message implements the above suggestion,
> and also fixes the testcase with -mtune=atom. However, I have no performance
> data to base cost values on, so the patch artificially rises the cost of
> DFmode vector insns for 20:
> + /* FIXME: The value here is arbitrary
> + and could potentially be improved with analysis. */
> + if (vectype && GET_MODE_INNER (TYPE_MODE (vectype)) == DFmode
> + && !TARGET_VECTORIZE_DOUBLE)
> + cost += 20;
If V2DFmode moves are fine(?) then maybe not do this for the load/store
kinds - this means only handling vector_stmt this way (and maybe
vect_promote_demote?) - at least make sure to not handle scalar_*
(not sure if vectype is always NULL for those -- docs say only
memory ops may depend on vectype).
Instead of += 20 I'd have done *= <factor> to
make it more independent of the absolute value of the cost numbers.
If you'd do the cost adjustment in ix86_add_stmt_cost you have more control
over the details (there's also similar offsetting for silvermont)
> > not sure why we override TYPE_MODE with preferred_simd_mode. It's not
> > that the x86 backend will emit word_mode loads/stores for V2DFmode
> > loads/stores on i?86 with -mtune=atom?
> Oh... no. We *do* have V2DFmode, but we want to avoid it as much as possible.
That's what I thought.