https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77478
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2016-09-22
Known to work| |6.1.0
Ever confirmed|0 |1
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Alexander Monakov from comment #7)
> Richard, I don't believe this is a dup. According to my git-bisect, this was
> fixed or made latent during gcc-6 development by your patch:
>
> https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00120.html
> [PATCH] Consolidate alignment folding
> (this is r225310 on trunk)
Specifically the tree-vect-loop-manip.c change.
Without it we have after vectorization
<bb 3>:
_86 = (unsigned int) n_7(D);
_87 = (unsigned int) i_8;
niters.21_85 = _86 - _87;
_89 = (long unsigned int) i_8;
_90 = _89 * 4;
# PT = nonlocal
# ALIGN = 16, MISALIGN = 0
vectp.22_88 = f_11(D) + _90;
_92 = (unsigned long) vectp.22_88;
_93 = _92 & 15;
_94 = _93 >> 2;
_95 = -_94;
_96 = (unsigned int) _95;
_97 = _96 & 3;
prolog_loop_niters.23_91 = MIN_EXPR <niters.21_85, _97>;
if (niters.21_85 <= 6)
goto <bb 4>;
else
goto <bb 5>;
...
but vectp.22_88 is not aligned to 16 bytes.
> How to go forward from here?
Backporting
Index: gcc/tree-vect-loop-manip.c
===================================================================
--- gcc/tree-vect-loop-manip.c (revision 240342)
+++ gcc/tree-vect-loop-manip.c (working copy)
@@ -1886,7 +1886,7 @@ vect_gen_niters_for_prolog_loop (loop_ve
gimple_seq new_stmts = NULL;
bool negative = tree_int_cst_compare (DR_STEP (dr), size_zero_node) < 0;
tree offset = negative
- ? size_int (-TYPE_VECTOR_SUBPARTS (vectype) + 1) : NULL_TREE;
+ ? size_int (-TYPE_VECTOR_SUBPARTS (vectype) + 1) : size_zero_node;
tree start_addr = vect_create_addr_base_for_vector_ref (dr_stmt,
&new_stmts, offset, loop);
tree type = unsigned_type_for (TREE_TYPE (start_addr));
looks like the way to go forward.
> (about the alignment dumping patchlet, I think it would be nice to have this
> functionality on trunk, can I help with that? is there something I'm missing
> about this patch that makes it unsuitable for trunk as-is?)
Only that it makes -vops even more noisy.
