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?
