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 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? > > 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.