https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96239
--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:cd676dfa57e643a4f7d8445e6ebad0f21cf3fd84 commit r11-6115-gcd676dfa57e643a4f7d8445e6ebad0f21cf3fd84 Author: Jakub Jelinek <ja...@redhat.com> Date: Wed Dec 16 13:08:07 2020 +0100 bswap: Handle vector CONSTRUCTORs [PR96239] The following patch teaches the bswap pass to handle for small (2/4/8 byte long) vectors a CONSTRUCTOR by determining if the bytes of the constructor come from non-vector sources and are either nop or bswap and changing the CONSTRUCTOR in that case to VIEW_CONVERT_EXPR from scalar integer to the vector type. Unfortunately, as I found after the patch was written, due to pass ordering this doesn't really fix the original testcase, just the one I wrote, because both loop and slp vectorization is done only after the bswap pass. A possible way out of that would be to perform just this particular bswap optimization (i.e. for CONSTRUCTOR assignments with integral vector types call find_bswap_or_nop and bswap_replace if successful) also during the store merging pass, it isn't really a store, but the store merging pass already performs bswapping when handling store, so it wouldn't be that big hack. What do you think? 2020-12-16 Jakub Jelinek <ja...@redhat.com> PR tree-optimization/96239 * gimple-ssa-store-merging.c (find_bswap_or_nop): Handle a vector CONSTRUCTOR. (bswap_replace): Likewise. * gcc.dg/pr96239.c: New test.
