[mlir][SPIR-V] Fix wrongly placed Rationale section.

[mravishankar]

Minor edit.

mlir/docs/Dialects/SPIR-V.md

 
 *   [include/mlir/Dialect/SPIRV/Passes.h][MlirSpirvPasses] contains SPIR-V
     specific analyses and transformations.
 *   [include/mlir/Dialect/SPIRV/SPIRVLowering.h][MlirSpirvLowering] contains
     type converters and other utility functions.
 
 These common utilities are implemented in the `MLIRSPIRVTransforms` library.
 
-## Contribution
-
-All kinds of contributions are highly appreciated! :) We have GitHub issues for
-tracking the [dialect][GitHubDialectTracking] and
-[lowering][GitHubLoweringTracking] development. You can find todo tasks there.
-The [Code organization](#code-organization) section gives an overview of how
-SPIR-V related functionalities are implemented in MLIR. This section gives more
-concrete steps on how to contribute.
-
 ## Rationale
 
-## Lowering `memref`s to `!spv.array<..>` and `!spv.rtarray<..>`.
+### Lowering `memref`s to `!spv.array<..>` and `!spv.rtarray<..>`.
 
 The LLVM dialect lowers `memref` types to a `MemrefDescriptor`:
 
 ```
 struct MemrefDescriptor {
   void *allocated_ptr; // Pointer to the base allocation.
   void *aligned_ptr;   // Pointer within base allocation which is aligned to
                        // the value set in the memref.
   size_t offset;       // Offset from aligned_ptr from where to get values
                        // corresponding to the memref.
   size_t shape[rank];  // Shape of the memref.
   size_t stride[rank]; // Strides used while accessing elements of the memref.
 };
 ```
 
 In SPIR-V dialect, we chose not to use a `MemrefDescriptor`. Instead a `memref`
 is lowered directly to a `!spv.ptr<!spv.array<nelts x elem_type>>` when the
 `memref` is statically shaped, and `!spv.ptr<!spv.rtarray<elem_type>>` when the
 `memref` is dynamically shaped. The rationale behind this choice is described
 below.
 
 1.  Inputs/output buffers to a SPIR-V kernel are specified using
-    [`OpVariable`][SpirvOpVariable] inside
-    [interface storage classes][VulkanShaderInterfaceStorageClass] (e.g.,
-    Uniform, StorageBuffer, etc.), while kernel private variables reside in
-    non-interface storage classes (e.g., Function, Workgroup, etc.). By default,
-    Vulkan-flavored SPIR-V requires logical addressing mode: one cannot
-    load/store pointers from/to variables and cannot perform pointer arithmetic.
-    Expressing a struct like `MemrefDescriptor` in interface storage class
-    requires special addressing mode
+    [`OpVariable`][SpirvOpVariable] inside [interface storage
+    classes][VulkanShaderInterfaceStorageClass] (e.g., Uniform, StorageBuffer,
+    etc.), while kernel private variables reside in non-interface storage
+    classes (e.g., Function, Workgroup, etc.). By default, Vulkan-flavored
+    SPIR-V requires logical addressing mode: one cannot load/store pointers
+    from/to variables and cannot perform pointer arithmetic.  Expressing a
+    struct like `MemrefDescriptor` in interface storage class requires special
+    addressing mode
     ([PhysicalStorageBuffer][VulkanExtensionPhysicalStorageBuffer]) and
     manipulating such a struct in non-interface storage classes requires special
     capabilities ([VariablePointers][VulkanExtensionVariablePointers]).
     Requiring these two extensions together will significantly limit the
     Vulkan-capable device we can target; basically ruling out mobile support..
 
 1.  An alternative to having one level of indirection (as is the case with
     `MemrefDescriptor`s), is to embed the `!spv.array` or `!spv.rtarray`
     directly in the `MemrefDescriptor`, Having such a descriptor at the ABI
     boundary implies that the first few bytes of the input/output buffers would
     need to be reserved for shape/stride information. This adds an unnecessary
     burden on the host side.
 
 1.  A more performant approach would be to have the data be an `OpVariable`,
     with the shape and strides passed using a separate `OpVariable`. This has
     further advantages:
 
     *   All the dynamic shape/stride information of the `memref` can be combined
-        into a single descriptor. Descriptors are
-        [limited resources on many Vulkan hardware][VulkanGPUInfoMaxPerStageDescriptorStorageBuffers].
-        So combining them would help make the generated code more portable
-        across devices.
+        into a single descriptor. Descriptors are [limited resources on many
+        Vulkan hardware][VulkanGPUInfoMaxPerStageDescriptorStorageBuffers].  So
+        combining them would help make the generated code more portable across
+        devices.
     *   If the shape/stride information is small enough, they could be accessed
         using [PushConstants][VulkanPushConstants] that are faster to access and
         avoid buffer allocation overheads. These would be unnecessary if all
         shapes are static. In the dynamic shape cases, a few parameters are
         typically enough to compute the shape of all `memref`s used/referenced
         within the kernel making the use of PushConstants possible.
     *   The shape/stride information (typically) needs to be update less
         frequently than the data stored in the buffers. They could be part of
         different descriptor sets.
 
+## Contribution
+
+All kinds of contributions are highly appreciated! :) We have GitHub issues for
+tracking the [dialect][GitHubDialectTracking] and
+[lowering][GitHubLoweringTracking] development. You can find todo tasks there.
+The [Code organization](#code-organization) section gives an overview of how
+SPIR-V related functionalities are implemented in MLIR. This section gives more
+concrete steps on how to contribute.
+
 ### Automated development flow
 
 One of the goals of SPIR-V dialect development is to leverage both the SPIR-V
 [human-readable specification][SpirvSpec] and
 [machine-readable grammar][SpirvGrammar] to auto-generate as much contents as
 possible. Specifically, the following tasks can be automated (partially or
 fully):