It seems the conclusion on PowerPC is to XFAIL the test on powerpc64 (there will
be XPASSes with -mcpu=power7 or -mcpu=power8). Which is what the original patch
does (https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01979.html). So,
Ping.
Thanks, Alan
On 21/12/15 15:33, Bill Schmidt wrote:
On Mon, 2015-12-21 at 15:22 +0000, Alan Lawrence wrote:
On 21/12/15 14:59, Bill Schmidt wrote:
On powerpc64, the test passes with -mcpu=power8 (the loop is vectorized as a
reduction); however, without that, similar code is generated to Alpha (the
vectorizer decides the reduction is not worthwhile without SIMD support), and
the test fails; hence, I've XFAILed for powerpc, but I think I could condition
the XFAIL on powerpc64 && !check_p8vector_hw_available, if preferred?
Fun.
Does it work with -mcpu=power7?
Yes, it works with -mcpu=power7, as well as -mcpu=power8, but not e.g.
-mcpu=power6.
Bill: What GCC DejaGNU incantation would you like to see?
This sounds like more fallout from unaligned accesses being faster on
POWER8 than previous hardware. What about conditioning the XFAIL on
{ powerpc*-*-* && { ! vect_hw_misalign } }
-- does this work properly?
Not on a stage1 compiler - check_p8vector_hw_available itself requires being
able to run executables - I'll check on gcc112. However, both look like they're
really about the host (ability to execute an asm instruction), not the target
(/ability for gcc to output such an instruction)....
Hm, that looks like a pervasive problem for powerpc. There are a number
of things that are supposed to be testing effective target but rely on
check_p8vector_hw_available, which as you note requires executing an
instruction and is really about the host. We need to clean that up; I
should probably open a bug. Kind of amazed this has gotten past us for
a couple of years.
For now, just XFAILing for powerpc seems the best alternative for this
test.
Thanks,
Bill
--Alan
