Allow mixed vector sizes within a single vectorised stmt
authorRichard Sandiford <richard.sandiford@arm.com>
Thu, 14 Nov 2019 15:16:40 +0000 (15:16 +0000)
committerRichard Sandiford <rsandifo@gcc.gnu.org>
Thu, 14 Nov 2019 15:16:40 +0000 (15:16 +0000)
commit05101d1b575a57ca26e4275e971da85a0dd1d52a
tree078be5300253c526cd4166b2aa26d4e2433c135d
parent74166aabeb7f22990476b1169bba031b8323ee92
Allow mixed vector sizes within a single vectorised stmt

Although a previous patch allowed mixed vector sizes within a vector
region, we generally still required equal vector sizes within a vector
stmt.  Specifically, vect_get_vector_types_for_stmt computes two vector
types: the vector type corresponding to STMT_VINFO_VECTYPE and the
vector type that determines the minimum vectorisation factor for the
stmt ("nunits_vectype").  It then required these two types to be
the same size.

There doesn't seem to be any need for that restriction though.  AFAICT,
all vectorizable_* functions either do their own compatibility checks
or don't need to do them (because gimple guarantees that the scalar
types are compatible).

It should always be the case that nunits_vectype has at least as many
elements as the other vectype, but that's something we can assert for.

I couldn't resist a couple of other tweaks while there:

- there's no need to compute nunits_vectype if its element type is
  the same as STMT_VINFO_VECTYPE's.

- it's useful to distinguish the nunits_vectype from the main vectype
  in dump messages

- when reusing the existing STMT_VINFO_VECTYPE, it's useful to say so
  in the dump, and say what the type is

2019-11-14  Richard Sandiford  <richard.sandiford@arm.com>

gcc/
* tree-vect-stmts.c (vect_get_vector_types_for_stmt): Don't
require vectype and nunits_vectype to have the same size;
instead assert that nunits_vectype has at least as many
elements as vectype.  Don't compute a separate nunits_vectype
if the scalar type is obviously the same as vectype's.
Tweak dump messages.

From-SVN: r278244
gcc/ChangeLog
gcc/tree-vect-stmts.c