Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70012 reports that the subject
test case is now failing in some circumstances. Prior to POWER8, the test
was checking for conditions that apply when data alignment is unknown; either
peeling for alignment or versioning for alignment may be used. With POWER8,
however, neither is necessary because we have efficient unaligned memory
accesses. So the test case needs some adjustment.
Interpreting the original intent of the test case is a little difficult.
The use of the vect_alignment_reachable test seems odd. Looking at
testsuite/lib/target-supports.exp, vect_alignment_reachable is equivalent
to vect_aligned_arrays || natural_alignment_32. But vect_aligned_arrays
is always 0 for powerpc*-*-*, so we might as well just be testing
natural_alignment_32.
It appears that the intent is for peeling to occur for 64-bit Darwin, but
otherwise versioning for alignment is expected. So actually
vect_alignment_reachable should be replaced by ! natural_alignment_32,
and ! vect_alignment_reachable should be replaced by natural_alignment_32.
In other words, for whatever reason these tests appear to be backward.
I suspect there have been changes to target-supports.exp over time that
have left this test slightly bit-rotten.
I've added a separate test for whether versioning occurs (which should
happen for server targets on POWER7, for example), since just testing for
vectorization doesn't test this.
I asked Iain Sandoe to test this on Darwin, and he reported that this is
not quite right for darwin9 with -m64. Unfortunately he will be traveling
for a while and won't be able to investigate till he returns. He's asked
me to leave the test as is without skipping Darwin so that the bug for
Darwin is not hidden, and he and I will work together to fix that at a
later time. But I would like to get this issue cleared up for the server
targets now, hence the patch submission.
Tested on powerpc64le-unknown-linux-gnu (POWER8) and on
powerpc64-unknown-linux-gnu (POWER7) with correct behavior. Is this ok
for trunk?
Thanks,
Bill
2017-02-01 Bill Schmidt <wschm...@linux.vnet.ibm.com>
* gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c: Adjust test
conditions.
Index: gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c
===================================================================
--- gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c (revision
245029)
+++ gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c (working copy)
@@ -36,7 +36,12 @@ int main (void)
}
/* Peeling to align the store is used. Overhead of peeling is too high. */
-/* { dg-final { scan-tree-dump-times "vectorization not profitable" 1 "vect" {
target vector_alignment_reachable } } } */
+/* { dg-final { scan-tree-dump-times "vectorization not profitable" 1 "vect" {
target { ! natural_alignment_32 } } } } */
-/* Versioning to align the store is used. Overhead of versioning is not too
high. */
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target {!
vector_alignment_reachable} } } } */
+/* Vectorization occurs, either because overhead of versioning is not
+ too high, or because the hardware supports efficient unaligned accesses. */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target {
natural_alignment_32 } } } } */
+
+/* Versioning to align the store is used. Overhead of versioning is not
+ too high. */
+/* { dg-final { scan-tree-dump-times "loop versioned for vectorization to
enhance alignment" 1 "vect" { target { natural_alignment_32 && { !
vect_hw_misalign } } } } } */
