Bug 70012 - test case gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails
Summary: test case gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 6.0
: P3 normal
Target Milestone: ---
Assignee: Bill Schmidt
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-29 04:25 UTC by Bill Seurer
Modified: 2017-02-01 22:15 UTC (History)
2 users (show)

See Also:
Host: powerpc*-*-*
Target: powerpc*-*-*
Build: powerpc*-*-*
Known to work:
Known to fail:
Last reconfirmed: 2017-01-23 00:00:00


Attachments
Proposed patch (429 bytes, patch)
2017-01-23 18:52 UTC, Bill Schmidt
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Bill Seurer 2016-02-29 04:25:32 UTC
This fails on both BE and LE and fails with both gcc 5 and gcc 6.  It does not fail with gcc 4.9.  It has been failing since at least December 2015.

Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c   -fno-diagnostics-show-caret -fdiagnostics-color=never   -O2 -ftree-vectorize -fvect-cost-model=dynamic -fno-common -maltivec -fdump-tree-vect-details -S   -o costmodel-vect-33.s    (timeout = 300)
spawn /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -ftree-vectorize -fvect-cost-model=dynamic -fno-common -maltivec -fdump-tree-vect-details -S -o costmodel-vect-33.s
PASS: gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c (test for excess errors)
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c scan-tree-dump-times vect "vectorization not profitable" 1
Comment 1 Richard Biener 2016-02-29 09:49:51 UTC
Might be a testsuite artifact in not reaching the cost model check but rejecting vectorization earlier (try bumping N to 32, after peeling for alignment no
vectorized iteration would be left so we don't peel for alignment anymore
thus we can't handle the store).
Comment 2 Bill Schmidt 2017-01-23 17:01:57 UTC
For POWER8 or later, this test isn't useful as we just go ahead and vectorize the loop.  In these processors we have better performance of misaligned vector loads and stores, so we are more aggressive under the cost model.  At a minimum we need to skip this test when TARGET_EFFICIENT_UNALIGNED_VSX = 1.

I note from the automated testers that we fail this test on POWER7 BE also, though, so there must be more to it than that.  I'll go poke at that next.

Confirmed, btw.
Comment 3 Bill Schmidt 2017-01-23 18:34:27 UTC
It looks to me like vect_alignment_reachable is the wrong test to be using here.  This is equivalent to vect_aligned_arrays || natural_alignment_32.  vect_aligned_array is always 0 for powerpc*-*-*.  natural_alignment_32 is always 1 for powerpc*-*-*, except for 64-bit Darwin.

I think the intent may be that peeling will occur for 64-bit Darwin, but otherwise versioning for alignment will occur.  So I think that vect_alignment_reachable should be replaced by ! natural_alignment_32, and ! vect_alignment_reachable should be replaced by natural_alignment_32.  I.e., for whatever reason these tests appear to be backward.

This change should make the testcase succeed on ppc64 BE and LE, but the success is misleading for P8 and P9, as we are no longer truly testing for versioning on those.  So we probably still need to exclude models with efficient support for unaligned vectors.
Comment 4 Bill Schmidt 2017-01-23 18:52:07 UTC
Created attachment 40568 [details]
Proposed patch

Attaching proposed patch.  Iain, would you be able to test this on Darwin 32- and 64-bit and see whether it makes sense?
Comment 5 Iain Sandoe 2017-01-28 20:50:11 UTC
(In reply to Bill Schmidt from comment #4)
> Created attachment 40568 [details]
> Proposed patch
> 
> Attaching proposed patch.  Iain, would you be able to test this on Darwin
> 32- and 64-bit and see whether it makes sense?

On darwin (powerpc-darwin9, trunk 244915) the patch flips the fail from m32 -> m64.  I.E. without the patch m64 passes and m32 fails; with the patch, the inverse.

I haven't built powerpc64-darwin9 in quite a while, so no comment there.

Apologies, but will have defer analysis for a while.
Comment 6 Bill Schmidt 2017-01-30 15:34:46 UTC
(In reply to Iain Sandoe from comment #5)
> (In reply to Bill Schmidt from comment #4)
> > Created attachment 40568 [details]
> > Proposed patch
> > 
> > Attaching proposed patch.  Iain, would you be able to test this on Darwin
> > 32- and 64-bit and see whether it makes sense?
> 
> On darwin (powerpc-darwin9, trunk 244915) the patch flips the fail from m32
> -> m64.  I.E. without the patch m64 passes and m32 fails; with the patch,
> the inverse.
> 
> I haven't built powerpc64-darwin9 in quite a while, so no comment there.
> 
> Apologies, but will have defer analysis for a while.

Hi Iain,

If you get a chance to just send me the vectorization dump file from each of -m32 and -m64, I can figure out why the tests fail for powerpc-darwin9 -m64.  My guess from what I'm seeing is that powerpc64-darwin9 will have the same characteristics as powerpc-darwin9 -m64.

Thanks,
Bill
Comment 7 Bill Schmidt 2017-02-01 22:12:28 UTC
Author: wschmidt
Date: Wed Feb  1 22:11:57 2017
New Revision: 245108

URL: https://gcc.gnu.org/viewcvs?rev=245108&root=gcc&view=rev
Log:
2017-02-01  Bill Schmidt  <wschmidt@linux.vnet.ibm.com>

	PR target/70012
	* gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c: Adjust test
	conditions.


Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c
Comment 8 Bill Schmidt 2017-02-01 22:15:05 UTC
Fixed for server targets.  We will defer 64-bit Darwin until Iain returns from travels.