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

[Florian Hahn via cfe-dev]

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 <https://reviews.llvm.org/D59832>.

Cheers,
Florian


> On Aug 7, 2019, at 08:25, Sjoerd Meijer via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> 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 <https://reviews.llvm.org/rL366989>
> [2] https://reviews.llvm.org/D65197 <https://reviews.llvm.org/D65197>
> [3] https://reviews.llvm.org/D65776 <https://reviews.llvm.org/D65776>
> [4] https://bugs.llvm.org/show_bug.cgi?id=27643 <https://bugs.llvm.org/show_bug.cgi?id=27643>
> _______________________________________________
> 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 <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190812/ef21baaf/attachment.html>