diff options
author | Richard Sandiford <richard.sandiford@arm.com> | 2025-01-28 14:45:11 +0000 |
---|---|---|
committer | Richard Sandiford <richard.sandiford@arm.com> | 2025-01-28 14:45:11 +0000 |
commit | 98b2009b8768f8790dff9edbe00742bcdf2b7482 (patch) | |
tree | d37c47abecfba1e65769984f03c803a5babca65f /libjava/testsuite/libjava.compile/static_2.java | |
parent | ea578dd251eaf6304b0c95acc107f9a4d63bee8f (diff) | |
download | gcc-master.zip gcc-master.tar.gz gcc-master.tar.bz2 |
vectorizable_slp_permutation_1 has two ways of generating the
permutations: one that looks for repeating patterns and one that
calculates the permutation index for every output element individually.
The former works for VLA and VLS whereas the latter only works for VLS.
There are two justifications for using the repeating code for VLS:
it gives more testing coverage, and it should reduce the analysis
overhead for common cases. This PR kind-of demonstrates both:
the VLS coverage was showing a bug in the analysis shortcut.
The bug seems to go back to g:ab7e60cec1a6, which added the
repeating_p path. It generated N copies of the permutation vector
in the repeating case, but didn't multiply the number of permutation
instructions for costing purposes by N. So we seem to have been
undercounting ncopies>1 permutations all this time...
The problem became more visible with g:8157f3f2d211, which extended
the repeating code to handle more cases.
In the patch, I think noutputs is in practice always a multiple
of unpack_factor, but it seemed more future-proof to handle the
general case.
gcc/
PR tree-optimization/117270
* tree-vect-slp.cc (vectorizable_slp_permutation_1): Make nperms
account for the number of times that each permutation will be used
during transformation.
Diffstat (limited to 'libjava/testsuite/libjava.compile/static_2.java')
0 files changed, 0 insertions, 0 deletions