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

Sjoerd Meijer via cfe-dev cfe-dev at lists.llvm.org
Sun Aug 11 23:11:12 PDT 2019


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

Cheers,
Sjoerd.
________________________________
From: Philip Reames <listmail at philipreames.com>
Sent: 09 August 2019 23:47
To: Sjoerd Meijer <Sjoerd.Meijer at arm.com>; cfe-dev at lists.llvm.org <cfe-dev at lists.llvm.org>
Cc: nd <nd at arm.com>
Subject: Re: [cfe-dev] Behaviour of loop pragmas and transformation options



On 8/7/19 12:25 AM, Sjoerd Meijer via cfe-dev 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).
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.

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



_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190812/27aa55cd/attachment.html>


More information about the cfe-dev mailing list