[cfe-dev] Behaviour of loop pragmas and transformation options

[Sjoerd Meijer via cfe-dev]

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.

________________________________
From: florian_hahn at apple.com <florian_hahn at apple.com> on behalf of Florian Hahn <florian_hahn at apple.com>
Sent: 13 August 2019 10:24
To: Sjoerd Meijer <Sjoerd.Meijer at arm.com>
Cc: Michael Kruse <llvm at meinersbur.de>; nd <nd at arm.com>; cfe-dev at lists.llvm.org <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] Behaviour of loop pragmas and transformation options

Hi,

On Aug 13, 2019, at 09:56, Sjoerd Meijer via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190813/fbccec38/attachment.html>