[MLIR][SPIRVToLLVM] Updated documentation on entry points and not supported ops

[georgemitenkov]

Summary

This patch addresses two issues:

1. Not supported ops are updated to pick up the changes in the

SPIR-V dialect.

2. Conversion on spv.ExecutionMode is updated.

[ftynse]

mlir/docs/SPIRVToLLVMDialectConversion.md

387

What's the LLVM equivalent? LLVM does not allow arrays without size.

[georgemitenkov]

mlir/docs/SPIRVToLLVMDialectConversion.md

387

I guess I didn't put it clear enough here! What I meant here is that we translate to

struct {
  int32_t executionMode;
};

if there are no values and to

struct {
  int32_t executionMode;
  int32_t values[];
};

if they exist.

[georgemitenkov]

Added a clearer explanation of how execution mode is
converted when there are no values associated with it.

mlir/docs/SPIRVToLLVMDialectConversion.md

 :-------------: | :--------------------: | :--------------------:
 vector          | `spv.CompositeExtract` | `llvm.extractelement`
 vector          | `spv.CompositeInsert`  | `llvm.insertelement`
 non-vector      | `spv.CompositeExtract` | `llvm.extractvalue`
 non-vector      | `spv.CompositeInsert`  | `llvm.insertvalue`
 
 ### `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).
+entry points in LLVM. At the moment, we use the following approach:
+
+* `spv.EntryPoint` is simply removed.
+
+* In contrast, `spv.ExecutionMode` may contain important information about the
+  entry point. For example, `LocalSize` provides information about the
+  work-group size that can be reused.
+
+  In order to preserve this inforamtion, `spv.ExecutionMode` is converted to
+  a struct global variable that stores the execution mode id and any variables
+  associated with it. In C, the struct has the structure shown below.
+
+  ```C
+  struct {
+    int32_t executionMode;
+    int32_t values[]; // optional values
+  };
+  ```
+
+  ```mlir
+  // spv.ExecutionMode @empty "ContractionOff"
+  llvm.mlir.global external constant @{{.*}}() : !llvm.struct<(i32)> {
+    %0   = llvm.mlir.undef : !llvm.struct<(i32)>
+    %1   = llvm.mlir.constant(31 : i32) : !llvm.i32
+    %ret = llvm.insertvalue %1, %0[0 : i32] : !llvm.struct<(i32)>
+    llvm.return %ret : !llvm.struct<(i32)>
+  }
+  ```
 
 ### 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

 // %1 = llvm.mlir.constant(dense<[2, 3, 4]> : vector<3xi32>) : !llvm.vec<3 x i32>
 %1 = spv.constant dense<[2, 3, 4]> : vector<3xui32>
 ```
 
 ### Not implemented ops
 
 There is no support of the following ops:
 
-*   All Atomic ops
+*   All atomic ops
+*   All group ops
 *   All matrix ops
-*   All GroupNonUniform ops
+*   All OCL ops
 
 As well as:
 
 *   spv.CompositeConstruct
 *   spv.ControlBarrier
 *   spv.CopyMemory
 *   spv.FMod
+*   spv.GLSL.Acos
+*   spv.GLSL.Asin
+*   spv.GLSL.Atan
+*   spv.GLSL.Cosh
+*   spv.GLSL.FSign
 *   spv.GLSL.SAbs
+*   spv.GLSL.Sinh
 *   spv.GLSL.SSign
-*   spv.GLSL.FSign
 *   spv.MemoryBarrier
 *   spv.mlir.referenceof
 *   spv.SMod
 *   spv.specConstant
-*   spv.SubgroupBallotKHR
 *   spv.Unreachable
+*   spv.VectorExtractDynamic
 
 ## Control flow conversion
 
 ### Branch ops
 
 `spv.Branch` and `spv.BranchConditional` are mapped to `llvm.br` and
 `llvm.cond_br`. Branch weights for `spv.BranchConditional` are mapped to
 corresponding `branch_weights` attribute of `llvm.cond_br`. When translated to