aboutsummaryrefslogtreecommitdiff
path: root/gcc/c/c-parser.c
diff options
context:
space:
mode:
authorWilco Dijkstra <wdijkstr@arm.com>2016-11-14 11:51:33 +0000
committerWilco Dijkstra <wilco@gcc.gnu.org>2016-11-14 11:51:33 +0000
commitdb4a1c18ceb5aede224c92ec4c86723f6fb93514 (patch)
tree4db5c2ad9238d945e3706325100f5638472d8299 /gcc/c/c-parser.c
parent725bbb80d69c0c0c72b2e83100f6c57dbf38e3e2 (diff)
downloadgcc-db4a1c18ceb5aede224c92ec4c86723f6fb93514.zip
gcc-db4a1c18ceb5aede224c92ec4c86723f6fb93514.tar.gz
gcc-db4a1c18ceb5aede224c92ec4c86723f6fb93514.tar.bz2
The existing vector costs stop some beneficial vectorization.
The existing vector costs stop some beneficial vectorization. This is mostly due to vector statement cost being set to 3 as well as vector loads having a higher cost than scalar loads. This means that even when we vectorize 4x, it is possible that the cost of a vectorized loop is similar to the scalar version, and we fail to vectorize. Using a cost of 3 for a vector operation suggests they are 3 times as expensive as scalar operations. Since most vector operations have a similar throughput as scalar operations, this is not correct. Using slightly lower values for these heuristics now allows this loop and many others to be vectorized. On a proprietary benchmark the gain from vectorizing this loop is around 15-30% which shows vectorizing it is indeed beneficial. * config/aarch64/aarch64.c (cortexa57_vector_cost): Change vec_stmt_cost, vec_align_load_cost and vec_unalign_load_cost. From-SVN: r242383
Diffstat (limited to 'gcc/c/c-parser.c')
0 files changed, 0 insertions, 0 deletions