[PATCH] D77989: Allow disabling of vectorization using internal options

Teresa Johnson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Apr 12 19:46:52 PDT 2020


tejohnson created this revision.
tejohnson added reviewers: fhahn, wmi.
Herald added subscribers: cfe-commits, dexonsmith, steven_wu, hiraditya.
Herald added a project: clang.

Currently, the internal options -vectorize-loops, -vectorize-slp, and
-interleave-loops do not have much practical effect. This is because
they are used to initialize the corresponding flags in the pass
managers, and those flags are then unconditionally overwritten when
compiling via clang or via LTO from the linkers. The only exception was
-vectorize-loops via opt because of some special hackery there.

While vectorization could still be disabled when compiling via clang,
using -fno-[slp-]vectorize, this meant that there was no way to disable
it when compiling in LTO mode via the linkers. This only affected
ThinLTO, since for regular LTO vectorization is done during the compile
step for scalability reasons. For ThinLTO it is invoked in the LTO
backends.

This patch makes it so the internal options can actually be used to
disable these optimizations. Ultimately, the best long term solution is
to mark the loops with metadata (similar to the approach used to fix
-fno-unroll-loops in D77058 <https://reviews.llvm.org/D77058>), but this enables a shorter term
workaround, and actually makes these internal options useful.

I constant propagated the initial values of these internal flags into
the pass manager flags (for some reasons vectorize-loops and
interleave-loops were initialized to true, while vectorize-slp was
initialized to false). As mentioned above, they are overwritten
unconditionally so this doesn't have any real impact, and these initial
values aren't particularly meaningful.

I then changed the passes to check the internl values and return without
performing the associated optimization when false (I changed the default
of -vectorize-slp to true so the options behave similarly). I was able
to remove the hackery in opt used to get -vectorize-loops=false to work,
as well as a special option there used to disable SLP vectorization.

Finally, I changed thinlto-slp-vectorize-pm.c to:
a) Only test SLP (moved the loop vectorization checking to a new test).
b) Use code that is slp vectorized when it is enabled, and check that
instead of whether the pass is enabled.
c) Test the new behavior of -vectorize-slp.
d) Test both pass managers.

The loop vectorization (and associated interleaving) testing I moved to
a new thinlto-loop-vectorize-pm.c test, with several changes:
a) Changed the flags on the interleaving testing so that it will
actually interleave, and check that.
b) Test the new behavior of -vectorize-loops and -interleave-loops.
c) Test both pass managers.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77989

Files:
  clang/test/CodeGen/thinlto-loop-vectorize-pm.c
  clang/test/CodeGen/thinlto-slp-vectorize-pm.c
  llvm/include/llvm/Passes/PassBuilder.h
  llvm/include/llvm/Transforms/Vectorize/LoopVectorize.h
  llvm/include/llvm/Transforms/Vectorize/SLPVectorizer.h
  llvm/lib/Passes/PassBuilder.cpp
  llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
  llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
  llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
  llvm/test/Transforms/SLPVectorizer/X86/opt.ll
  llvm/tools/opt/opt.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D77989.256909.patch
Type: text/x-patch
Size: 18721 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200413/b7c21fba/attachment.bin>


More information about the llvm-commits mailing list