We have recently added support for a new loop pragma ‘vectorize_predicate’ .
During review of the LLVM part that does the actual transformation , the
question was raised if ‘vectorize_predicate’ should imply ‘vectorize(enable)’.
I agree that this is indeed what users would most likely expect and so I
created a patch for that .
During review of , Florian mentioned bug report  supporting the case that
users indeed expect that more specific pragmas such as e.g. vectorize_width(4)
should imply vectorize(enable), but this is currently not the case. But our
docs for example mention: "The following example implicitly enables
vectorization and interleaving by specifying a vector width and interleaving
count", and so we have an inconsistency in the docs and implementation. But as
I have e.g. no clue what the behaviour could be of "vectorize(disable)
vectorize_predicate(enable)", I would say the docs are right and the
implementation is wrong.
Michael mentioned that the situation with for example loop unroll pragmas
‘unroll(enable) unroll_count(4)’ is not very different. Pragma ‘unroll_count’
also does not set ‘llvm.loop.unroll.enable’, but it is handled by the
LoopUnroll pass itself and so we end up with checks like this:
bool ExplicitUnroll = PragmaCount > 0 || PragmaFullUnroll ||
PragmaEnableUnroll || UserUnrollCount;
And again, this is very similar to ‘vectorize_width’, and we have different
checks to see if vectorization is enabled.
Because of the many inconsistencies, we came to the conclusion in  that we
don’t know how know how to (best) implement that setting an transformation
option implies setting the transformation.
My proposal would be that the transformation options imply the transformations
by setting the enable flag of that transformation. Thus, vectorize options
vectorize_width, vectorize_predicate, etc., set vectorize(enable), and unroll
option unroll count set unroll(enable).
Any thoughts on this welcome.