This is an archive of the discontinued LLVM Phabricator instance.

Allow disabling of vectorization using internal options
ClosedPublic

Authored by tejohnson on Apr 12 2020, 7:41 PM.

Details

Summary

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), 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.

Diff Detail

Event Timeline

tejohnson created this revision.Apr 12 2020, 7:41 PM
wmi added a comment.Apr 13 2020, 10:11 PM

The patch makes the reasoning about when the internal flags will take effect much easier.

One question is, with the change, the internal flags can only be used to disable loop vectorization/slp vectorization/loop interleaving, but not to enable them. Can we treat them in the way that the flags in PipelineTuningOptions contain the default values set by Opt Level, and the internal flags can override them, which can either enable or disable the vectorizations/interleaving.

To do that, we need to let SLPVectorizerPass be added into pass manager anyway and pass PTO.SLPVectorization as a param (now adding SLPVectorizerPass is guarded by PTO.SLPVectorization). Whether SLPVectorizerPass will be performed can be decided inside of SLPVectorizerPass.

llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
7675–7678

Use boolean operator || instead of bitwise operator?

wmi added a comment.Apr 13 2020, 11:15 PM
In D77989#1979725, @wmi wrote:

The patch makes the reasoning about when the internal flags will take effect much easier.

One question is, with the change, the internal flags can only be used to disable loop vectorization/slp vectorization/loop interleaving, but not to enable them. Can we treat them in the way that the flags in PipelineTuningOptions contain the default values set by Opt Level, and the internal flags can override them, which can either enable or disable the vectorizations/interleaving.

I realize it is not easy to do since the internal flags are bool type, and there is no easy way to specify unspecified values for the internal flags which could allow us to use the default values set by Opt Level. Ideally, we want -slp-vectorize=true to enable slp, -slp-vectorize=false to disable slp, no -slp-vectorize flag to keep the default value, but that is not easy to achieve with current commandline library.

In D77989#1979772, @wmi wrote:
In D77989#1979725, @wmi wrote:

The patch makes the reasoning about when the internal flags will take effect much easier.

One question is, with the change, the internal flags can only be used to disable loop vectorization/slp vectorization/loop interleaving, but not to enable them. Can we treat them in the way that the flags in PipelineTuningOptions contain the default values set by Opt Level, and the internal flags can override them, which can either enable or disable the vectorizations/interleaving.

I realize it is not easy to do since the internal flags are bool type, and there is no easy way to specify unspecified values for the internal flags which could allow us to use the default values set by Opt Level. Ideally, we want -slp-vectorize=true to enable slp, -slp-vectorize=false to disable slp, no -slp-vectorize flag to keep the default value, but that is not easy to achieve with current commandline library.

Right. The reason I went with the strategy of using the false value to disable is that they are all on by default (at least >O0), and it seemed more useful to have a way to disable.

wmi accepted this revision.Apr 14 2020, 2:22 PM

There is a comment about the bitwise operator, otherwise LGTM.

This revision is now accepted and ready to land.Apr 14 2020, 2:22 PM
tejohnson marked an inline comment as done.Apr 14 2020, 4:57 PM
tejohnson added inline comments.
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
7675–7678

Good catch, fixed.

tejohnson updated this revision to Diff 257562.Apr 14 2020, 4:58 PM

Address comment

This revision was automatically updated to reflect the committed changes.