[PATCH] D88408: [docs] Revise loop terminology reference.

Michael Kruse via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 28 19:27:49 PDT 2020


Meinersbur added a comment.

I think the document is more useful as a reference than a text-book reading.



================
Comment at: llvm/docs/LoopTerminology.rst:212
+that does not anything in its body. If the loop is infinite, this
+optimization will result in an "infinite" performance speed-up. A call
+to the intrinsic :ref:`llvm.sideeffect<llvm_sideeffect>` has to be added
----------------
baziotis wrote:
> This is one of the best explanations for the removal of an infinite loop :)
> 
> This paragraph may raise questions though. e.g. what is the formal reasoning ? (forward progress guarantee). I think it's ok to mention here that the optimizer can do things like that without further formalities. But maybe also link to another place that explains the formalities if anyone's interested (and I don't pretend to have a good place to link for LLVM IR. Anything I know, which is not much, I've seen it on llvm-dev here and there).
Indeed I'd prefer to not spat out all the details here. A good place to link to instead would be D65718, but is has been abandoned. There is still a discussion about this on the mailing-list and I don't want to introduce these into the fundamentals document.

Not even the LangRef about `llvm.sideeffect` is more detailed! That's where I'd expect those clarifications.


================
Comment at: llvm/docs/LoopTerminology.rst:144
+
+ * The number of executions of the loop header before leaving the loop is the **loop trip count**. If the loop should not be executed at all, a **loop guard** must skip the entire loop:
+
----------------
baziotis wrote:
> Meinersbur wrote:
> > baziotis wrote:
> > > I think that the reference to the loop guard here is out of the blue it raises questions. It may be better to just leave the loop rotate part reference it.
> > > 
> > > Also, we might want to add "loop trip count (also called iteration count)".
> > The existence of a loop guard is independent of the loop-rotated normal form, the same way a preheader may exist before LoopSimplify.
> Yes, but does LoopInfo recognize it if it's not from LoopRotate ? e.g. if I write `if (cond) { do { ... } while (cond); }` in the source, will it recognize that it has a guard ? I thought that for the compiler, a guard is something only the compiler inserts while with the above wording, a guard can also exist already.
> 
> I think I explained badly my confusion when I read this: I think it's not clear what is a loop guard, who inserts it (if anyone) and when (partly this resulted from the use of "should not" and "must" above). Maybe something like that?
> A guard is any block that dominates the header (it can be the header) and guards the body of the loop from not being entered if the loop condition is false before the first iteration. The compiler may insert such a guard after some transformation to ensure correctness (e.g. LoopRotate).
> 
> The wording could be better but please tell me what you think.
LoopRotation does not recognize guards. Guards being created is just the typical sideeffect of moving the first execution of the loop header (which in a typical for-loop contains the loop condition) before the loop, thus creating a guard. There could also be multiple "guards" skipping the loop checking for different conditions.

I used introduced the loop guard here to illustrate that a loop trip count of 1 does not mean the the loop body (in the sense of the input language) has been executed, and how that is avoided (possibly also by frontend IR generators), and to show and name a pattern one often finds in the wild.

A loop guard cannot be the header, the point of the guard is to skip the loop. The loop is not skipped if one first has to enter the loop to check the guard condition.
For the point of optimization, the advantage of not entering the loop at all is stronger assumptions for the preheader (e.g. more things can be hoisted into the preheader), but I would prefer to not go into optimization details here; there is a link to the LoopRotation section. I did not even explain what the preheader use useful for.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88408



More information about the llvm-commits mailing list