On Fri, May 21, 2021 at 5:00 PM Uros Bizjak via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > Here it is, the patch that enables auto-vectorization for 32bit modes. > > Sent as RFC, because the patch fails some vectorizer scans, as it > obviously enables more vectorization to happen: > > Running target unix > FAIL: gcc.dg/vect/pr71264.c -flto -ffat-lto-objects scan-tree-dump > vect "vectorized 1 loops in function" > FAIL: gcc.dg/vect/pr71264.c scan-tree-dump vect "vectorized 1 loops in > function" > FAIL: gcc.dg/vect/slp-28.c -flto -ffat-lto-objects > scan-tree-dump-times vect "vectorized 1 loops" 1 > FAIL: gcc.dg/vect/slp-28.c -flto -ffat-lto-objects > scan-tree-dump-times vect "vectorizing stmts using SLP" 1 > FAIL: gcc.dg/vect/slp-28.c scan-tree-dump-times vect "vectorized 1 loops" 1 > FAIL: gcc.dg/vect/slp-28.c scan-tree-dump-times vect "vectorizing > stmts using SLP" 1 > FAIL: gcc.dg/vect/slp-3.c -flto -ffat-lto-objects > scan-tree-dump-times vect "vectorized 3 loops" 1 > FAIL: gcc.dg/vect/slp-3.c -flto -ffat-lto-objects > scan-tree-dump-times vect "vectorizing stmts using SLP" 3 > FAIL: gcc.dg/vect/slp-3.c scan-tree-dump-times vect "vectorized 3 loops" 1 > FAIL: gcc.dg/vect/slp-3.c scan-tree-dump-times vect "vectorizing stmts > using SLP" 3 > > > Running target unix/-m32 > FAIL: gcc.dg/vect/no-vfa-vect-101.c scan-tree-dump-times vect "can't > determine dependence" 1 > FAIL: gcc.dg/vect/no-vfa-vect-102.c scan-tree-dump-times vect > "possible dependence between data-refs" 1 > FAIL: gcc.dg/vect/no-vfa-vect-102a.c scan-tree-dump-times vect > "possible dependence between data-refs" 1 > FAIL: gcc.dg/vect/no-vfa-vect-37.c scan-tree-dump-times vect "can't > determine dependence" 2 > FAIL: gcc.dg/vect/pr71264.c -flto -ffat-lto-objects scan-tree-dump > vect "vectorized 1 loops in function" > FAIL: gcc.dg/vect/pr71264.c scan-tree-dump vect "vectorized 1 loops in > function" > FAIL: gcc.dg/vect/slp-28.c -flto -ffat-lto-objects > scan-tree-dump-times vect "vectorized 1 loops" 1 > FAIL: gcc.dg/vect/slp-28.c -flto -ffat-lto-objects > scan-tree-dump-times vect "vectorizing stmts using SLP" 1 > FAIL: gcc.dg/vect/slp-28.c scan-tree-dump-times vect "vectorized 1 loops" 1 > FAIL: gcc.dg/vect/slp-28.c scan-tree-dump-times vect "vectorizing > stmts using SLP" 1 > FAIL: gcc.dg/vect/slp-3.c -flto -ffat-lto-objects > scan-tree-dump-times vect "vectorized 3 loops" 1 > FAIL: gcc.dg/vect/slp-3.c -flto -ffat-lto-objects > scan-tree-dump-times vect "vectorizing stmts using SLP" 3 > FAIL: gcc.dg/vect/slp-3.c scan-tree-dump-times vect "vectorized 3 loops" 1 > FAIL: gcc.dg/vect/slp-3.c scan-tree-dump-times vect "vectorizing stmts > using SLP" 3 > FAIL: gcc.dg/vect/vect-104.c -flto -ffat-lto-objects > scan-tree-dump-times vect "possible dependence between data-refs" 1 > FAIL: gcc.dg/vect/vect-104.c scan-tree-dump-times vect "possible > dependence between data-refs" 1
Yeah, it's a bit iffy to adjust expectations. If there's a way to disable vectorization for 32bit modes on x86 that might be a way to "fix" them, otherwise we're lacking a way to query for available vector modes/sizes in the dejagnu vect targets. There's available_vector_sizes but it's implementation is hardly complete nor is size the only important thing (FP vs. INT). At least one could add a vect32 predicate similar to the existing vect64 one. Richard. > Please also note that V4QI and V2HI modes do not use MMX registers, so > auto-vectorization can also be enabled on 32bit x86 targets. > > Uros.
