[PATCH] D49281: [Unroll/UnrollAndJam/Vectorizer/Distribute] Add followup loop attributes.

[Michael Kruse via Phabricator via llvm-commits]

Meinersbur added a comment.

In https://reviews.llvm.org/D49281#1189643, @hsaito wrote:

> What I'm not seeing from this RFC/patch is that, if the programmer specifies transformation behavior A -> B -> C, what happens if transformation A does not kick-in? Should we just warn that "A did not happen" and stop processing the request B and C?


Yes. A warning will be emitted by the `-transform-warning` pass (Please see Passes.rst). B and C cannot apply on a loop that does not exist.

> Also, if the programmer requests that the loop to be distribute in three ways and specify different transformations for each, what should the latter transformation do if the loop is distributed in two ways or four ways?

The current LoopDistribution pass unfortunately does not support this, by a goal is to make the user able to define what code should become their own loop. See [[ A Proposal for Loop-Transformation Pragmas | https://arxiv.org/abs/1805.03374 ]].
For the current LoopDistribution pass, only two categories of followup-attributes can be defined `noncyclic` and `cyclic`. The `noncyclic` category can be added to multiple loops.

> If we are serious about introducing this kind of features, we should clearly define what should happen when the programmer intention cannot be satisfied well enough ---- when we should continue honoring  and when we should stop honoring. If we say "we should stop in all those circumstances", that should simplify the problem a lot. If we say "we should allow to continue on subset of those cases", we should clearly state which subset and why. If there are any prior discussions (or descriptions within this patch) along this lines, please point me to that.

Documented in `TransformMetadata.rst` line 57ff.



================
Comment at: docs/TransformMetadata.rst:163
+full unrolling, partial unrolling of a loop with constant trip count or
+runtime unrolling of a loop with a trip count unknown at compile-time.
+
----------------
dmgreen wrote:
> Do you think it's worth mentioning unroll.count and unroll.disable etc, before jumping into the followup metadata?
Yes, maybe, but they are also already documented in the `LangRef.rst`. Please understand that the goal in this patch is to define a transformation model for each pass such that it is clear what are those followup-loops, not to write an exhaustive documentation.


Repository:
  rL LLVM

https://reviews.llvm.org/D49281