aboutsummaryrefslogtreecommitdiff
path: root/gcc/gimple-range.cc
diff options
context:
space:
mode:
authorRichard Biener <rguenther@suse.de>2022-02-09 10:55:18 +0100
committerRichard Biener <rguenther@suse.de>2022-02-09 14:03:31 +0100
commitda2bf62d9e2a25f2d6a99176144c250b51fbdee7 (patch)
treec9b7384cd0a3becee9cb8f89c0c407b79d9e76f0 /gcc/gimple-range.cc
parentab0b5fbfe90168d2e470aefb19e0cf31526290bc (diff)
downloadgcc-da2bf62d9e2a25f2d6a99176144c250b51fbdee7.zip
gcc-da2bf62d9e2a25f2d6a99176144c250b51fbdee7.tar.gz
gcc-da2bf62d9e2a25f2d6a99176144c250b51fbdee7.tar.bz2
tree-optimization/104445 - check for vector extraction support
This adds a missing check to epilogue reduction re-use, namely that we can do hi/lo extracts from the vector when demoting it to the epilogue vector size. I've chosen to add a can_vec_extract helper to optabs-query.h, in the future we might want to simplify the vectorizers life by handling vector-from-vector extraction via BIT_FIELD_REFs during RTL expansion via the mode punning when the vec_extract is not directly supported. I'm not 100% sure we can always do the punning of the vec_extract result to a vector mode of the same size, but then I'm also not sure how to check for that (the vectorizer doesn't in other places it does that at the moment, but I suppose we eventually just go through memory there)? 2022-02-09 Richard Biener <rguenther@suse.de> PR tree-optimization/104445 PR tree-optimization/102832 * optabs-query.h (can_vec_extract): New. * optabs-query.cc (can_vec_extract): Likewise. * tree-vect-loop.cc (vect_find_reusable_accumulator): Check we can extract a hi/lo part from the larger vector, rework check iteration from larger to smaller sizes. * gcc.dg/vect/pr104445.c: New testcase.
Diffstat (limited to 'gcc/gimple-range.cc')
0 files changed, 0 insertions, 0 deletions