[MLIR][SPIRVToLLVM] Updated the documentation for the conversion

[georgemitenkov]

Summary

This patch updates the SPIR-V to LLVM conversion manual.
Particularly, the following sections are added:

• spv.EntryPoint/spv.ExecutionMode handling
• Mapping for spv.AccessChain
• Change in allowed storage classes for spv.globalVariable
• Change of the runner section name

[mravishankar]

mlir/docs/SPIRVToLLVMDialectConversion.md

368–369

I think the last statement can be dropped.

475–477

Dont see how this is related to multithreading?

[georgemitenkov]

Addressed comments.

mlir/docs/SPIRVToLLVMDialectConversion.md

 `spv.SGreaterThanEqual`               | `llvm.icmp "sge"`
 `spv.SLessThan`                       | `llvm.icmp "slt"`
 `spv.SLessThanEqual`                  | `llvm.icmp "sle"`
 `spv.UGreaterThan`                    | `llvm.icmp "ugt"`
 `spv.UGreaterThanEqual`               | `llvm.icmp "uge"`
 `spv.ULessThan`                       | `llvm.icmp "ult"`
 `spv.ULessThanEqual`                  | `llvm.icmp "ule"`
 
+### `spv.EntryPoint` and `spv.ExecutionMode`
+
+**Note: these conversions are likely to be changed in the future**
+
+First of all, it is important to note that there is no direct representation of
+entry points in LLVM. At the moment, we choose to **remove these ops**, assuming
+that the module generated from SPIR-V has no other internal functions (This
+assumption is actually made in [`mlir-spirv-cpu-runner`](#`mlir-spirv-cpu-runner`)).
+
+However, these ops can be used to see which functions in the module are entry
+point functions. `spv.ExecutionMode` also carries the metadata associated with
+the entry point such as `LocalSize`, which indicates the workgroup size in the
+x, y, and z dimensions. It will be useful to represent this on the LLVM side
+(TODO). The possible implementation may be a global struct that holds the
+information associated with the given entry point.
+
 ### Logical ops
 
 Logical ops follow a similar pattern as bitwise ops, with the difference that
 they operate on `i1` or vector of `i1` values. The following mapping is used to
 emulate SPIR-V ops behaviour:
 
 SPIR-V Dialect op                     | LLVM Dialect op
 :-----------------------------------: | :-----------------------------------:

 %0 = spv.LogicalNot %op : i1  =>  %0    = llvm.xor %op, %mask : !llvm.i1
 ```
 
 ### Memory ops
 
 This section describes the conversion patterns for SPIR-V dialect operations
 that concern memory.
 
+#### `spv.AccessChain`
+
+`spv.AccessChain` is mapped to `llvm.getelementptr` op. In order to create a
+valid LLVM op, we also add a 0 index to the `spv.AccessChain`'s indices list in
+order to go through the pointer.
+
+```mlir
+// Access the 1st element of the array
+%i   = spv.constant 1: i32
+%var = spv.Variable : !spv.ptr<!spv.struct<f32, !spv.array<4xf32>>, Function>
+%el  = spv.AccessChain %var[%i, %i] : !spv.ptr<!spv.struct<f32, !spv.array<4xf32>>, Function>, i32, i32
+
+// Corresponding LLVM dialect code
+%i   = ...
+%var = ...
+%0   = llvm.mlir.constant(0 : i32) : !llvm.i32
+%el  = llvm.getelementptr %var[%0, %i, %i] : (!llvm.ptr<struct<packed (float, array<4 x float>)>>, !llvm.i32, !llvm.i32, !llvm.i32)
+```
+
 #### `spv.Load` and `spv.Store`
 
 These ops are converted to their LLVM counterparts: `llvm.load` and
 `llvm.store`. If the op has a memory access attribute, then there are the
 following cases, based on the value of the attribute:
 
 * **Aligned**: alignment is passed on to LLVM op builder, for example:
   ```mlir
module {
   llvm.mlir.global private @struct() : !llvm.struct<packed (float, [10 x float])>
   llvm.func @func() {
     %0 = llvm.mlir.addressof @struct : !llvm.ptr<struct<packed (float, [10 x float])>>
     llvm.return
   }
 }
 ```
 
-At the moment, only current invocation is in conversion's scope. This means that
-global variables with pointers of `Input`, `Output` and `Private` storage
-classes are supported. Moreover, `bind` that specifies the descriptor set and
-binding number and `built_in` that specifies SPIR-V `BuiltIn` decoration have
-also no conversion.
-
-Currently `llvm.mlir.global`s are created with `private` linkage for
-`Private` storage class and `External` for `Input`/`Output` storage classes,
-based on SPIR-V spec:
+The SPIR-V to LLVM conversion does not involve multithreading and modelling of
+workgroups or invocations. Therefore, we say that only current invocation is in
+conversion's scope. This means that global variables with pointers of `Input`,
+`Output`, and `Private` storage classes are supported. However, since there is
+no multithreading, we would also allow pointers with `StorageBuffer` storage
+class for executing [`mlir-spirv-cpu-runner`](#`mlir-spirv-cpu-runner`).
+
+Moreover, `bind` that specifies the descriptor set and the binding number and
+`built_in` that specifies SPIR-V `BuiltIn` decoration have no conversion into
+LLVM dialect.
+
+Currently `llvm.mlir.global`s are created with `private` linkage for `Private`
+storage class and `External` for other storage classes, based on SPIR-V spec:
 
 > By default, functions and global variables are private to a module and cannot
 be accessed by other modules. However, a module may be written to export or
 import functions and global (module scope) variables.
 
 If the global variable's pointer has `Input` storage class, then a `constant`
 flag is added to LLVM op:
 

 There is no support of the following ops:
 
 *   All Atomic ops
 *   All matrix ops
 *   All GroupNonUniform ops
 
 As well as:
 
-*   spv.AccessChain
 *   spv.CompositeConstruct
 *   spv.CompositeExtract
 *   spv.CompositeInsert
 *   spv.ControlBarrier
 *   spv.CopyMemory
-*   spv.EntryPoint
-*   spv.ExecutionMode
 *   spv.FMod
 *   spv.GLSL.SAbs
 *   spv.GLSL.SSign
 *   spv.GLSL.FSign
 *   spv.MemoryBarrier
 *   spv._reference_of
 *   spv.SMod
 *   spv.specConstant

 *   Memory model
 *   Version-Capability-Extension attribute
 
 `spv.module` is converted into `ModuleOp`. This plays a role of enclosing scope
 to LLVM ops. At the moment, SPIR-V module attributes are ignored.
 
 `spv._module_end` is mapped to an equivalent terminator `ModuleTerminatorOp`.
 
-## SPIR-V special ops
-
-**Note: this section is due to be implemented in August**
+## `mlir-spirv-cpu-runner`
 
-This section describes how SPIR-V specific ops, *e.g* `spv.specConstant`, are
-modelled in LLVM. It also provides information on `mlir-spirv-runner`.
+**Note: this is a section in progress, more information will appear soon**
 
 [LLVMFunctionAttributes]: https://llvm.org/docs/LangRef.html#function-attributes
 [SPIRVFunctionAttributes]: https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#_a_id_function_control_a_function_control