[Bug target/106038] x86_64 vectorization of ALU ops using xmm registers prematurely

[goldstein.w.n at gmail dot com]

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

--- Comment #5 from Noah Goldstein <goldstein.w.n at gmail dot com> ---
(In reply to Richard Biener from comment #4)
> The vectorizer does not anticipate store-merging performing "vectorization"
> in GPRs and thus the scalar cost is off (it also doesn't anticipate the
> different
> ISA constraints wrt xmm vs gpr usage).
> 
> I wonder if we should try to follow what store-merging would do with respect
> to "vector types", thus prefer "general vectors" (but explicitely via integer
> types since we can't have vector types with both integer and vector modes)
> when possible (for bit operations and plain copies).
> 
> scanning over an SLP instance (group) and substituting integer types for
> SLP_TREE_VECTYPE might be possible.  Doing this nicely somewhere is going to
> be more interesting.  Far away vectorizable_* should compute a set of
> { vector-type, cost } pairs from the set of input operand vector-type[, cost]
> pair sets.  Not having "generic" vectors as vector types and relying on
> vector lowering to expand them would be an incremental support step for this
> I guess.
> 
> "backwards STV" could of course also work on the target side.

backwards STV?