[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77621

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #11)
> (In reply to rguenther@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?
> 
> True.
> 
> > 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.