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

--- Comment #15 from UroŇ° Bizjak <ubizjak at gmail dot com> ---
(In reply to Richard Biener from comment #12)

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

Moves are fine, V2DFmode vector arithmetic insns (addpd, subpd, mulpd) have
much higher latencies (e.g. 6 for addpd, 9 for mulpd), comparing to their
{SF,DF}mode (or V4SFmode) versions (1 for addps, 2 for mulps).

> Instead of += 20 I'd have done *= <factor> to
> make it more independent of the absolute value of the cost numbers.

IMO, having no other data at hand than Agner Fog's instruction tables, it looks
that penalizing vector_stmt cost with a factor of 5 should be OK for a start.

> 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)

ix86_builtin_vectorization_cost is also called from there. OTOH,
ix86_add_stmt_cost uses some other arguments (e.g. location), which I think are
irrelevant to the insn type cost adjustment.

Let me play a bit with the patch.

Reply via email to