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

[Finkel, Hal J. via cfe-dev]

On 8/13/19 4:24 AM, Florian Hahn via cfe-dev wrote:
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.



I agree. The fact that this construct enables interleaving is non-obvious, and that might not be ideal. We do have a separate pragma for that. Nevertheless, we should certainly handle the width = 1 case; in general, the width might be a dependent value (e.g., a non-type template parameter).

 -Hal



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



_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190813/1a106f43/attachment.html>