Reformulate OrcJIT tutorial doc to make it more clear.

[sonson]

Summary

Fixed a minor writing error. The text was hard to understand.

[mehdi_amini]

llvm/docs/tutorial/BuildingAJIT2.rst

229–230

Probably should reflow here to preserve the 80cols

230

Nit: there is a trailing space here.

230

I think these two added new lines aren't needed, are they?

231

"Each layer can complete its own work ..." ?

234

Nit: You have some initial empty space at the beginning of these lines apparently

[sonson]

I fixed it as instructed by the reviewer.
Removed trailing spaces and no needed empty spaces.
Preserve 80cols at all lines.

Thank you.

[mehdi_amini]

llvm/docs/tutorial/BuildingAJIT2.rst

232

I'm not sure this sentence is actually more clear. You're trying to go from a passive form to an active form, but it goes with introducing someone as the subject, which does not seem like usual to me when describing some piece of code calling another piece of code.
Are you following some guidelines on technical documentation here?

[sonson]

I'm not sure this sentence is actually more clear. You're trying to go from a passive form to an active form, but it goes with introducing someone as the subject, which does not seem like usual to me when describing some piece of code calling another piece of code.
Are you following some guidelines on technical documentation here?

No.

I think it's more clear...
I'm not so sure about that. I'll think about it some more.

[dblaikie]

Probably worth including the JIT owner & author (@lhames) in reviews/changes to the JIT documentation.

[lhames]

Very belatedly: These changes look good to me. :)

llvm/docs/tutorial/BuildingAJIT2.rst

232

Agreed -- introducing "someone" here feels slightly awkward. I don't have strong feelings though, and the rest of the changes look good.

[sonson]

I do not have commit access, I need someone to land it.

Thank you for your review.

[xgupta]

llvm/docs/tutorial/BuildingAJIT2.rst

232

Yes, someone feels awkward.

[sonson]

This comment was removed by sonson.

[sonson]

Removed "someone" expression.

I replaced the sentence pointed out by three reviewers with the current one.

[mehdi_amini]

Can you rebase? Seems like your patch isn't written on top of main.

[sonson]

Fixed the patch, by rebasing.

[mehdi_amini]

llvm/docs/tutorial/BuildingAJIT2.rst

232

I'm not sure remove "the" from "to the layer's emit method" is correct here?

[sonson]

Fixed the patch, by rebasing.
Fixed 'the'.

llvm/docs/tutorial/BuildingAJIT2.rst

 ThreadSafeModule to a given JITDylib by wrapping it up in a
 ``MaterializationUnit`` (in this case a ``BasicIRLayerMaterializationUnit``).
 Most layers that derived from IRLayer can rely on this default implementation
 of the ``add`` method.
 
 These two operations, ``add`` and ``emit``, together constitute the layer
 concept: A layer is a way to wrap a part of a compiler pipeline (in this case
 the "opt" phase of an LLVM compiler) whose API is opaque to ORC with an
 interface that ORC can call as needed. The add method takes an
-module in some input program representation (in this case an LLVM IR module) and
-stores it in the target JITDylib, arranging for it to be passed back to the
-Layer's emit method when any symbol defined by that module is requested. Layers
-can compose neatly by calling the 'emit' method of a base layer to complete
-their work. For example, in this tutorial our IRTransformLayer calls through to
-our IRCompileLayer to compile the transformed IR, and our IRCompileLayer in turn
-calls our ObjectLayer to link the object file produced by our compiler.
-
-
-So far we have learned how to optimize and compile our LLVM IR, but we have not
-focused on when compilation happens. Our current REPL is eager: Each function
-definition is optimized and compiled as soon as it is referenced by any other
-code, regardless of whether it is ever called at runtime. In the next chapter we
-will introduce fully lazy compilation, in which functions are not compiled until
-they are first called at run-time. At this point the trade-offs get much more
-interesting: the lazier we are, the quicker we can start executing the first
-function, but the more often we will have to pause to compile newly encountered
-functions. If we only code-gen lazily, but optimize eagerly, we will have a
-longer startup time (as everything is optimized) but relatively short pauses as
-each function just passes through code-gen. If we both optimize and code-gen
-lazily we can start executing the first function more quickly, but we will have
-longer pauses as each function has to be both optimized and code-gen'd when it
-is first executed. Things become even more interesting if we consider
-interprocedural optimizations like inlining, which must be performed eagerly.
-These are complex trade-offs, and there is no one-size-fits all solution to
-them, but by providing composable layers we leave the decisions to the person
-implementing the JIT, and make it easy for them to experiment with different
-configurations.
+module in some input program representation (in this case an LLVM IR module)
+and stores it in the target ``JITDylib``, arranging for it to be passed back
+to layer's emit method when someone requests any symbols defined by the module.
+Each layer can complete its own work by calling the ``emit`` method of its base
+layer. For example, in this tutorial our IRTransformLayer calls through to
+our IRCompileLayer to compile the transformed IR, and our IRCompileLayer in
+turn calls our ObjectLayer to link the object file produced by our compiler.
+
+So far we have learned how to optimize and compile our LLVM IR, but we have
+not focused on when compilation happens. Our current REPL optimizes and
+compiles each function as soon as it is referenced by any other code,
+regardless of whether it is ever called at runtime. In the next chapter we
+will introduce a fully lazy compilation, in which functions are not compiled
+until they are first called at run-time. At this point the trade-offs get much
+more interesting: the lazier we are, the quicker we can start executing the
+first function, but the more often we will have to pause to compile newly
+encountered functions. If we only code-gen lazily, but optimize eagerly, we
+will have a longer startup time (as everything is optimized at that time) but
+relatively short pauses as each function just passes through code-gen. If we
+both optimize and code-gen lazily we can start executing the first function
+more quickly, but we will have longer pauses as each function has to be both
+optimized and code-gen'd when it is first executed. Things become even more
+interesting if we consider interprocedural optimizations like inlining, which
+must be performed eagerly. These are complex trade-offs, and there is no
+one-size-fits all solution to them, but by providing composable layers we leave
+the decisions to the person implementing the JIT, and make it easy for them to
+experiment with different configurations.
 
 `Next: Adding Per-function Lazy Compilation <BuildingAJIT3.html>`_
 
 Full Code Listing
 =================
 
 Here is the complete code listing for our running example with an
 IRTransformLayer added to enable optimization. To build this example, use: