There's inconsistent handling of the cpart_size == cnunits which
currently avoids reporting peeling for gaps being insufficient, but
the following condition which is enough to trigger it,
cremain + group_size < cpart_size with cpart_size == cnunits is
equal to the condition that brings us here in the first place,
maybe_lt (remain + group_size, nunits). The following fixes this
by not checking cpart_size against special values.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-stmts.cc (get_group_load_store_type): Do not
exempt cpart_size == cnunits from failing.
---
gcc/tree-vect-stmts.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 011d66747ec..458056dd13d 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -2196,7 +2196,7 @@ get_group_load_store_type (vec_info *vinfo, stmt_vec_info
stmt_info,
if (!nunits.is_constant (&cnunits)
|| !LOOP_VINFO_VECT_FACTOR (loop_vinfo).is_constant (&cvf)
|| (((cremain = (group_size * cvf - gap) % cnunits), true)
- && ((cpart_size = (1 << ceil_log2 (cremain))) != cnunits)
+ && ((cpart_size = (1 << ceil_log2 (cremain))), true)
&& (cremain + group_size < cpart_size
|| vector_vector_composition_type
(vectype, cnunits / cpart_size,
--
2.43.0
