https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126028
--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Richard Biener <[email protected]>: https://gcc.gnu.org/g:fb0838bc1073aa5f22ec38e0cca2d70d625c6d71 commit r17-2654-gfb0838bc1073aa5f22ec38e0cca2d70d625c6d71 Author: Richard Biener <[email protected]> Date: Wed Jul 15 10:37:57 2026 +0200 Support two-lane vector BB reductions without target support The following implements BB reduction epilog handling for two-lane vectors with lane extracts. This allows targets to omit defining reduc_*_scal optabs for two lane vector modes and enables trivial handling of in-order reductions with two lanes. The former is one issue we run into with PR126028 on x86_64. This causes some no-op vectorization since we now accept vector costs equal to scalar costs. For gcc.target/i386/pr54400.c this shows that after SLP vectorizing a two lane reduction we are no longer able to match up the x86 haddpd instruction I have sent a partial x86 backend fix. For g++.target/i386/pr114187.C it shows the usual argument/return costing difficulties but also a too broad testcase and inadverted coverage of -m32 - I have adjusted the testcase. PR tree-optimization/126028 * tree-vect-slp.cc (vect_slp_check_for_roots): Move fold-left reduction check ... (vectorizable_bb_reduc_epilogue): ... here and allow two reduction lanes to be unaffected. Handle the two vector lane without target support for the reduction. (vectorize_slp_instance_root_stmt): Implement manual two-lane reduction. * gcc.dg/vect/bb-slp-reduc-1.c: New testcase for a two-lane in-order reduction. * c-c++-common/vector-subscript-4.c: Use -fno-vectorize. * g++.target/i386/pr114187.C: Narrow pattern to better only catch the reported issue.
