Behaviour of loop pragmas and transformation options

We have recently added support for a new loop pragma ‘vectorize_predicate’ [1].

During review of the LLVM part that does the actual transformation [2], 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 [3].

During review of [3], Florian mentioned bug report [4] 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 [3] 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.

[1] https://reviews.llvm.org/rL366989

[2] https://reviews.llvm.org/D65197

[3] https://reviews.llvm.org/D65776

[4] https://bugs.llvm.org/show_bug.cgi?id=27643

I second this. The complexities of which pragmas enable which transforms should be handled entirely in Clang, with Clang responsible for emitting a consistent set of metadata flags to LLVM.Â

Thanks for your reply. This direction looked sensible, and I wanted to check if we weren’t missing anything.

Cheers,
Sjoerd.

Hi Sjoerd,

Thanks for writing this up! As Philip already mentioned, I think clang should handle enabling transforms by setting the corresponding enable metadata when more specific transform pragmas are used. This is what the expected behavior is according to the docs and the current implementation leads to surprising outcomes like in PR27643.

We probably should also enable required transformations like loop rotation when vectorization was requested via a pragma, as LoopVectorize requires rotated loops. Adam put up a patch for that a while ago https://reviews.llvm.org/D59832.

Cheers,
Florian

Hi,

if the consensus is that `vectorize_predicate()` should also set
`llvm.loop.vectorize.enable`, could you change the patch to apply this
also to `vectorize_width()`, `interleave_count()`?

I don think we need to change unroll_count() atm.

Michael

Hi,

Sure, I won’t mind fixing these other cases too while I am at it.

I think my only preference would be to make one functional change at a time (fix one pragma (option) at a time), because this has turned into a little project on itself and dealing with issues would be easier, unless a big-bang change would be preferred in this case for some reason and then I will address them all in D65776.

I think one thing we haven’t discussed yet is conflicting combinations like:

vectorize(enable) vectorize_width(1)

Should this enable of disable vectorisation? This is now important when an option implies setting the transformation. I think it probably makes most sense that enabling/disabling the transformation should take precedence over setting the transformation options, and so in this example vectorisation should be enabled. With this logic, the predicate hint is ignored because vectorisation is disabled in this case:

vectorize(disable) vectorize_predicate(enable)

which is what is being proposed in D65776.

After fixing the Clang behaviour, it would be good to revise the LLVM parts that check these transformations and options, to check things are consistent or can be simplified like the code example in the first message.

Cheers,
Sjoerd.

Hi,

Hi,

Sure, I won’t mind fixing these other cases too while I am at it.

I think my only preference would be to make one functional change at a time (fix one pragma (option) at a time), because this has turned into a little project on itself and dealing with issues would be easier, unless a big-bang change would be preferred in this case for some reason and then I will address them all in D65776.

Addressing it on a patch-per-pragma sounds good, thanks for picking this up!

I think one thing we haven’t discussed yet is conflicting combinations like:

I think we should agree on something like the following as a general rule to deal with such cases:

More specific transformation pragmas (e.g. vector_width) imply the transformation is enabled, as if it was enabled via the corresponding explicit pragma (e.g. vectorize(enable)). If the transformation is explicitly disabled (e.g. vectorize(disable)), that takes precedence over pragmas implicitly enabling it.

We should warn for obvious conflicts (like your second example), but we probably should not not put too much knowledge about the specific parameters into clang.

vectorize(enable) vectorize_width(1)

IMO we should enable the transformation and set vector_width=1 in the metadata. This might not make too much sense (it instructs LoopVectorize to only do interleaving), but I do not think it would be a good idea to add too much logic to validate parameter combinations to clang. We can always provide information via optimization remarks from the transforms.

Should this enable of disable vectorisation? This is now important when an option implies setting the transformation. I think it probably makes most sense that enabling/disabling the transformation should take precedence over setting the transformation options, and so in this example vectorisation should be enabled. With this logic, the predicate hint is ignored because vectorisation is disabled in this case:

vectorize(disable) vectorize_predicate(enable)

IMO it makes sense for the more explicit pragma (vectorize(disable)) to take precedence over the one that implicitly enables vectorization. We should disable vectorization via metadata.

Cheers,
Florian

Hi Florian,

I mostly agree with this summary:

More specific transformation pragmas (e.g. vector_width) imply the transformation is enabled, as if it was enabled via the corresponding explicit pragma (e.g. vectorize(enable)). If the transformation is explicitly disabled (e.g. vectorize(disable)), that takes precedence over pragmas implicitly enabling it.

Just a few minor corrections. In the the last sentence, “implicitly enabling it” should be “implying it”.

I think we can simplify things by simply not mentioning “explicit” or “more specific” etc. if we define:

  • transformations, e.g.: vectorize, unroll, etc.,

  • transformations options, e.g.: vectorize_width, vectorize_predicate, unroll_count, etc.

So the summary becomes something like:

Pragmas setting transformation options (e.g. vector_width) imply the transformation is enabled, as if it was enabled via the corresponding transformation pragma (e.g. vectorize(enable)). If the transformation is disabled (e.g. vectorize(disable)), that takes precedence over transformations option pragmas implying that transformation.

With this definition,

vectorize(enable) vectorize_width(1)

IMO we should enable the transformation and set vector_width=1 in the metadata.

I agree that this is could then be the expected behaviour (you could also argue that setting a value is not the same as disabling it). And this example is also straightforward indeed:

vectorize(disable) vectorize_predicate(enable)

IMO it makes sense for the more explicit pragma (vectorize(disable)) to take precedence over the one that implicitly enables vectorization.

It just follows from the definition.

Cheers,
Sjoerd.

Hi,