Apply suggestions from code review

Co-authored-by: Svetlana Karslioglu <svekars@fb.com>

Author: jerryzh168

prototype_source/pt2e_quantizer.rst

@@ -304,7 +304,7 @@ functions that are used in the example:
 
 A Note on IR for PT2E Quantization Flow
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-IR means the intermediate representation of the model, for example, ``torch`` IR (``torch.nn`` modules, ``torch.nn.functional`` ops) or ``aten`` IR (``torch.ops.aten.linear``, ...). PT2E Quantization Flow is using pre autograd aten IR (the output of `torch.export` API) so that we support training. As is shown before, we need to match the operator or operator patterns before we can do annotations on them, So the question is how do we match the pattern?
+**IR** stands for the **Intermediate Representation** of the model. For example, ``torch`` IR (``torch.nn`` modules, ``torch.nn.functional`` ops) or ``aten`` IR (``torch.ops.aten.linear``, ...). PT2E Quantization Flow is using pre autograd ATen IR (the output of ``torch.export`` API) so that we support training. As is shown before, we need to match the operator or operator patterns before we can do annotations on them. The question is, how do we match the pattern?
 
 1. Matching ``aten`` IR directly
 ------------------------------------
@@ -335,13 +335,13 @@ Example::
         # annotate conv and relu nodes
         ...
 
-However one problem for using this IR is that the representation might change if the PyTorch implementation for modules or functional ops changed. But this could be unexpected since modeling users typically assume that when the eager mode model code doesn't change, they should get the same model representation after program capture as well. One concrete effect for this problem is that if a ``Quantizer`` do annotations based on recognizing ``aten`` IR patterns, then it may fail to recognzing the pattern after PyTorch version update, and the same eager mode floating point may be left unquantized.
+However, an issue with this IR is that the representation might change if the PyTorch implementation for modules or functional ops changed. But this could be unexpected since modeling users typically assume that when the eager mode model code doesn't change, they should get the same model representation after program capture as well. One concrete effect for this problem is that if a ``Quantizer`` do annotations based on recognizing ``aten`` IR patterns, then it may fail to recognize the pattern after PyTorch version update, and the same eager mode floating point may be left unquantized.
 
 2. Using ``SubgraphMatcher``
 --------------------------------
-Because of this, we recommend people to recognize the pattern through ``SubgraphMatcher``, through capturing a ``torch`` IR pattern (with the same program capture used for capturing the floating point model), instead of using the ``aten`` IR pattern directly.
+Because of this, we recommend to recognize the pattern through ``SubgraphMatcher``, through capturing a ``torch`` IR pattern (with the same program capture used for capturing the floating point model), instead of using the ``aten`` IR pattern directly.
 
-Example::
+**Example:**::
 
   def conv_relu_pattern(x, weight, bias):
       conv = torch.nn.functional.conv2d(x, weight, bias)
@@ -358,15 +358,15 @@ Example::
       inputs[1].users[0].meta["quantization_annotation"] = ...
       output.meta["quantization_annotation"] = ...
 
-With this, the ``Quantizer`` will still be valid even when the implementation for nn modules and functionals changes, the ``aten`` IR for floating point model will change, but since we capture the pattern again instead of hardcoding the ``aten`` IR for the pattern, we'll get the updated ``aten`` IR as well and will still be able to match the pattern.
+With this, the ``Quantizer`` will still be valid even when the implementation for the ``nn`` modules and functionals changes, the ``aten`` IR for floating point model will change, but since we capture the pattern again instead of hardcoding the ``aten`` IR for the pattern, we'll get the updated ``aten`` IR as well and will still be able to match the pattern.
 
-One caveat is that if inputs of the pattern has multiple users, we don't have a good way to identify which user node we want to annotate except for checking the aten op target.
+One caveat is that if inputs of the pattern has multiple users, we don't have a good way to identify which user node we want to annotate except for checking the ``aten`` op target.
 
-Another caveat is that we need to make sure we have an exhaustive list of examples (e.g. 2D, 3D, 4D inputs, real v.s. symbolic inputs, training=True v.s. training=False etc.) for the pattern to make sure cover different possible ``aten`` IR outcomes captured from the ``torch`` IR pattern.
+Another caveat is that we need to make sure we have an exhaustive list of examples (such as 2D, 3D, 4D inputs, real vs. symbolic inputs, ``training=True`` vs. ``training=False``, and so on) for the pattern to make sure cover different possible ``aten`` IR outcomes captured from the ``torch`` IR pattern.
 
 3. Using ``SubgraphMatcherWithNameNodeMap``
 ----------------------------------------------
-We also introduced a different SubgraphMatcher util called ``SubgraphMatcherWithNameNodeMap`` to make it easier to query the nodes that people want to annotate.
+We also introduced a different ``SubgraphMatcher`` utility called ``SubgraphMatcherWithNameNodeMap`` to make it easier to query the nodes that people want to annotate.
 
 Example::
   
@@ -387,7 +387,7 @@ Example::
 
 This should be easier to use than the original ``SubgraphMatcher`` around finding the node we want to annotate or use. However, it may not work if some of the operators are captured as multiple ops. For example, if ``torch.nn.functional.conv2d`` is captured as multiple ops, then the inputs ``x``, ``weight``, ``bias`` may not be the direct inputs to the final operator marked by ``conv``, in this case we'll need to revert to the same way of access mentioned in the previous example.
 
-Example::
+**Example:**::
 
   for match in matches:
       # find input and output of the pattern