Re: [PATCH 4/4] Un-XFAIL ssa-dom-cse-2.c for most platforms

[Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>]

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
>