[PATCH] D65257: Describe resticted form of loops in the new loop terminogy documentation

[Michael Kruse via Phabricator via llvm-commits]

Meinersbur requested changes to this revision.
Meinersbur added inline comments.
This revision now requires changes to proceed.


================
Comment at: docs/LoopTerminology.rst:138-139
+core to the transforms we generally wish to perform.  Rather than a single
+catch all restriction, we have a number of fine grained predicates which
+can be uses as preconditions for loop transforms.  
+
----------------
I don't get this. Where can these predicates be used? More importantly, which pass ensures the restricted/normal/canonical forms?

I'd not describe a restricted loop forms in terms of an API call. That's what the merthod documentation/doxygen is for. If you are not a frequent user of the Loop class, it is not obvious what it means when e.g. `getLoopLatch()` return nullptr. The naive interpretation is "there is not latch". Rather it should be described as property of the CFG).


================
Comment at: docs/LoopTerminology.rst:160
+  
+It is generally reasonable to expect the above properties hold for loops of
+interest when a LoopPass runs inside of the LoopPassManager.  Additionally,
----------------
No; `LoopSimplifyPass` must have been added before or `simplifyLoop` run on it manually.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65257/new/

https://reviews.llvm.org/D65257