On Thu, 7 Nov 2019, Andre Vieira (lists) wrote:
> Hi,
>
> PR92351 reports a bug in which a wrongly aligned load is generated for an
> epilogue of a main loop for which we peeled for alignment. There is no way to
> guarantee that epilogue data accesses are aligned when the main loop is
> peeling for alignment.
>
> I also had to split vect-peel-2.c as there were scans there for the number of
> unaligned accesses that were vectorized, thanks to this change that now
> depends on whether we are vectorizing the epilogue, which will also contain
> unaligned accesses. Since not all targets need to be able to vectorize the
> epilogue I decided to disable epilogue vectorization for the version in which
> we scan the dumps and add a version that attempts epilogue vectorization but
> does not scan the dumps.
>
> Bootstrapped and regression tested on x86_64 and aarch64.
>
> Is this OK for trunk?
@@ -938,6 +938,18 @@ vect_compute_data_ref_alignment (dr_vec_info
*dr_info)
= exact_div (vect_calculate_target_alignment (dr_info),
BITS_PER_UNIT);
DR_TARGET_ALIGNMENT (dr_info) = vector_alignment;
+ /* If the main loop has peeled for alignment we have no way of knowing
+ whether the data accesses in the epilogues are aligned. We can't at
+ compile time answer the question whether we have entered the main
loop
or
+ not. Fixes PR 92351. */
+ if (loop_vinfo)
+ {
+ loop_vec_info orig_loop_vinfo = LOOP_VINFO_ORIG_LOOP_INFO
(loop_vinfo);
+ if (orig_loop_vinfo
+ && LOOP_VINFO_PEELING_FOR_ALIGNMENT (orig_loop_vinfo) != 0)
+ return;
+ }
so I'm not sure this is the correct place to do the fixup. Isn't the
above done when analyzing the loops with different vector size/mode?
So we don't yet know whether we analyze the loop as epilogue or
not epilogue? Looks like we at the moment always choose the
very first loop we analyze successfully as "main" loop?
So, can we do this instead in update_epilogue_loop_vinfo? There
we should also know whether we created the jump-around the
main vect loop.
> In the future I would like to look at allowing for misalignment analysis for
> cases in which both the number of iterations and iterations to peel are known
> at compile time, as in that case we shouldn't ever be skipping the main loop
> as we shouldn't be generating it.
>
> gcc/ChangeLog:
> 2019-11-07 Andre Vieira <andre.simoesdiasvie...@arm.com>
>
> * tree-vect-data-refs.c (vect_compute_data_ref_alignment): When we are
> peeling the main loop for alignment, make sure to set the misalignment
> of the epilogue's data references to DR_MISALIGNMENT_UNKNOWN.
>
> gcc/testsuite/ChangeLog:
> 2019-11-07 Andre Vieira <andre.simoesdiasvie...@arm.com>
>
> * gcc.dg/vect/vect-peel-2.c: Disable epilogue vectorization and
> split the source of this test to...
> * gcc.dg/vect/vect-peel-2-src.c: ... This.
> * gcc.dg/vect/vect-peel-2-epilogues.c: New test.
>
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
