[MLIR][SPIRVToLLVM] Updated LLVM types in the documentation

[georgemitenkov]

Summary

Updated the documentation with new MLIR LLVM types for
vectors, pointers, arrays and structs. Also, changed remaining
tabs to spaces.

mlir/docs/SPIRVToLLVMDialectConversion.md

 `f16`                                | `!llvm.half`
 `f32`                                | `!llvm.float`
 `f64`                                | `!llvm.double`
 
 ### Vector types
 
 SPIR-V Dialect                       | LLVM Dialect
 :----------------------------------: | :----------------------------------:
-`vector<<count> x <scalar-type>>`    | `!llvm<"<<count> x <scalar-type>>">`
+`vector<<count> x <scalar-type>>`    | `!llvm.vec<<count> x <scalar-type>>`
 
 ### Pointer types
 
 A SPIR-V pointer also takes a Storage Class. At the moment, conversion does
 **not** take it into account.
 
 SPIR-V Dialect                                | LLVM Dialect
 :-------------------------------------------: | :-------------------------:
-`!spv.ptr< <element-type>, <storage-class> >` | `!llvm.element-type*`
+`!spv.ptr< <element-type>, <storage-class> >` | `!llvm.ptr<<element-type>>`
 
 ### Array types
 
 SPIR-V distinguishes between array type and run-time array type, the length of
 which is not known at compile time. In LLVM, it is possible to index beyond the
 end of the array. Therfore, runtime array can be implemented as a zero length
 array type.
 
 Moreover, SPIR-V supports the notion of array stride. Note that this is **not**
 supported by type conversion at the moment.
 
 SPIR-V Dialect                        | LLVM Dialect
 :-----------------------------------: | :-----------------------------------:
-`!spv.array<<count> x <element-type>>`| `!llvm<"[<count> x <element-type>]">`
-`!spv.rtarray< <element-type> >`      | `!llvm<"[0 x <element-type>]">`
+`!spv.array<<count> x <element-type>>`| `!llvm.array<<count> x <element-type>>`
+`!spv.rtarray< <element-type> >`      | `!llvm.array<0 x <element-type>>`
 
 ### Struct types
 
 Members of SPIR-V struct types may have decorations and offset information.
 Currently, there is **no** support of member decorations conversion for structs.
 For more information see section on [Decorations](#Decorations-conversion). 
 
 Usually we expect that each struct member has a natural size and alignment.

 *   Structs with unnatural offset (*i.e.* offset that is not equal to cumulative
     size of the previous struct elements) are **not** supported. In this case,
     offsets can be emulated with padding fields (*e.g.* integers). However, such
     a design would require index recalculation in the conversion of ops that
     involve memmory addressing.
 
 Examples of SPIR-V struct conversion are:
 ```mlir
-!spv.struct<i8, i32>          =>  !llvm<"<{ i8, i32 }>">
-!spv.struct<i8 [0], i32 [4]>  =>  !llvm<"{ i8, i32 }">
+!spv.struct<i8, i32>          =>  !llvm.struct<packed (i8, i32)>
+!spv.struct<i8 [0], i32 [4]>  =>  !llvm.struct<(i8, i32)>
 
 // error
 !spv.struct<i8 [0], i32 [8]>
 ```
 
 ### Not implemented types
 
 The rest of the types not mentioned explicitly above are not supported by the
*   `offset` and `count` are always scalar. This means that we can have the
 
     To be able to proceed with conversion algorithms described below, all
     operands have to be of the same type and bitwidth. This requires
     broadcasting of `offset` and `count` to vectors, for example for the case
     above it gives:
 
     ```mlir
     // Broadcasting offset
-    %offset0 = llvm.mlir.undef : !llvm<"<2 x i8>">
+    %offset0 = llvm.mlir.undef : !llvm.vec<2 x i8>
     %zero = llvm.mlir.constant(0 : i32) : !llvm.i32
-    %offset1 = llvm.insertelement %offset, %offset0[%zero : !llvm.i32] : !llvm<"<2 x i8>">
+    %offset1 = llvm.insertelement %offset, %offset0[%zero : !llvm.i32] : !llvm.vec<2 x i8>
     %one = llvm.mlir.constant(1 : i32) : !llvm.i32
-    %vec_offset = llvm.insertelement  %offset, %offset1[%one : !llvm.i32] : !llvm<"<2 x i8>">
+    %vec_offset = llvm.insertelement  %offset, %offset1[%one : !llvm.i32] : !llvm.vec<2 x i8>
 
     // Broadcasting count
     // ...
     ```
 
 *   `offset` and `count` may have different bitwidths from `base`. In this case,
     both of these operands have to be zero extended (since they are treated as
     unsigned by the specification) or truncated. For the above example it would
     be:
 
     ```mlir
     // Zero extending offest after broadcasting
-    %res_offset = llvm.zext %vec_offset: !llvm<"<2 x i8>"> to !llvm<"<2 x i32>">
+    %res_offset = llvm.zext %vec_offset: !llvm.vec<2 x i8> to !llvm.vec<2 x i32>
     ```
 
     Also, note that if the bitwidth of `offset` or `count` is greater than the
     bitwidth of `base`, truncation is still permitted. This is because the ops have a
     defined behaviour with `offset` and `count` being less than the size of
     `base`. It creates a natural upper bound on what values `offset` and `count`
     can take, which is 64. This can be expressed in less than 8 bits.
 

 #### `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
-  // llvm.store %ptr, %val {alignment = 4 : i64} : !llvm<"float*">
+  // llvm.store %ptr, %val {alignment = 4 : i64} : !llvm.ptr<float>
   spv.Store "Function" %ptr, %val ["Aligned", 4] : f32
   ```
 * **None**: same case as if there is no memory access attribute.
 
 * **Nontemporal**: set `nontemporal` flag, for example:
   ```mlir
-  // %res = llvm.load %ptr {nontemporal} : !llvm<"float*">
+  // %res = llvm.load %ptr {nontemporal} : !llvm.ptr<float>
   %res = spv.Load "Function" %ptr ["Nontemporal"] : f32
   ```
 * **Volatile**: mark the op as `volatile`, for example:
   ```mlir
-  // %res = llvm.load volatile %ptr : !llvm<"float*">
+  // %res = llvm.load volatile %ptr : !llvm.ptr<float>
   %res = spv.Load "Function" %ptr ["Volatile"] : f32
   ```
 Otherwise the conversion fails as other cases (`MakePointerAvailable`,
 `MakePointerVisible`, `NonPrivatePointer`) are not supported yet.
 
 #### `spv.globalVariable` and `spv._address_of`
 
 `spv.globalVariable` is modelled with `llvm.mlir.global` op. However, there
spv.module Logical GLSL450 {
   spv.func @func() -> () "None" {
     %0 = spv._address_of @struct : !spv.ptr<!spv.struct<f32, !spv.array<10xf32>>, Private>
     spv.Return
   }
 }
 
 // Converted result
 module {
-  llvm.mlir.global private @struct() : !llvm<"<{ float, [10 x float] }>">
+  llvm.mlir.global private @struct() : !llvm.struct<packed (float, [10 x float])>
   llvm.func @func() {
-    %0 = llvm.mlir.addressof @struct : !llvm<"<{ float, [10 x float] }>*">
+    %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

 `spv.Variable` is modelled as `llvm.alloca` op. If initialized, an additional
 store instruction is used. Note that there is no initialization for arrays and
 structs since constants of these types are not supported in LLVM dialect (TODO).
 Also, at the moment initialization is only possible via `spv.constant`.
 
 ```mlir
 // Conversion of VariableOp without initialization
                                                                %size = llvm.mlir.constant(1 : i32) : !llvm.i32
-%res = spv.Variable : !spv.ptr<vector<3xf32>, Function>   =>   %res  = llvm.alloca  %size x !llvm<"<3 x float>"> : (!llvm.i32) -> !llvm<"<3 x float>*">
+%res = spv.Variable : !spv.ptr<vector<3xf32>, Function>   =>   %res  = llvm.alloca  %size x !llvm.vec<3 x float> : (!llvm.i32) -> !llvm.ptr<vec<3 x float>>
 
 // Conversion of VariableOp with initialization
                                                                %c    = llvm.mlir.constant(0 : i64) : !llvm.i64
 %c   = spv.constant 0 : i64                                    %size = llvm.mlir.constant(1 : i32) : !llvm.i32
-%res = spv.Variable init(%c) : !spv.ptr<i64, Function>    =>   %res   = llvm.alloca %[[SIZE]] x !llvm.i64 : (!llvm.i32) -> !llvm<"i64*">
-                                                               llvm.store %c, %res : !llvm<"i64*">
+%res = spv.Variable init(%c) : !spv.ptr<i64, Function>    =>   %res   = llvm.alloca %[[SIZE]] x !llvm.i64 : (!llvm.i32) -> !llvm.ptr<i64>
+                                                               llvm.store %c, %res : !llvm.ptr<i64>
 ```
 
 Note that simple conversion to `alloca` may not be sufficent if the code has
 some scoping. For example, if converting ops executed in a loop into `alloca`s,
 a stack overflow may occur. For this case, `stacksave`/`stackrestore` pair can
 be used (TODO).
 
 ### Miscellaneous ops with direct conversions

 hardware implementation might show unexpected behavior. Therefore, it is better
 to handle it case-by-case, given that the purpose of the conversion is not to
 cover all possible corner cases.
 
 ```mlir
 // %0 = llvm.mlir.constant(0 : i8) : !llvm.i8
 %0 = spv.constant  0 : i8
 
-// %1 = llvm.mlir.constant(dense<[2, 3, 4]> : vector<3xi32>) : !llvm<"<3 x i32>">
+// %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

 
 Control flow within `spv.selection` and `spv.loop` is lowered directly to LLVM
 via branch ops. The conversion can only be applied to selection or loop with all
 blocks being reachable. Moreover, selection and loop control attributes (such as
 `Flatten` or `Unroll`) are not supported at the moment.
 
 ```mlir
 // Conversion of selection
-%cond = spv.constant true                              %cond = llvm.mlir.constant(true) : !llvm.i1
+%cond = spv.constant true                               %cond = llvm.mlir.constant(true) : !llvm.i1
 spv.selection {
-  spv.BranchConditional %cond, ^true, ^false          llvm.cond_br %cond, ^true, ^false
+  spv.BranchConditional %cond, ^true, ^false            llvm.cond_br %cond, ^true, ^false
 
 ^true:                                                ^true:
-  // True block code                                    // True block code
-  spv.Branch ^merge                              =>      llvm.br ^merge
+  // True block code                                    // True block code
+  spv.Branch ^merge                             =>      llvm.br ^merge
 
-^false:                                               ^false:
-  // False block code                                   // False block code
-  spv.Branch ^merge                                      llvm.br ^merge
+^false:                                               ^false:
+  // False block code                                   // False block code
+  spv.Branch ^merge                                     llvm.br ^merge
 
-^merge:                                               ^merge:
-  spv._merge                                            llvm.br ^continue
+^merge:                                               ^merge:
+  spv._merge                                            llvm.br ^continue
 }
 // Remaining code                                     ^continue:
-                                                        // Remaining code
+                                                        // Remaining code
 ```
 
 ```mlir
 // Conversion of loop
 %cond = spv.constant true                               %cond = llvm.mlir.constant(true) : !llvm.i1
 spv.loop {
   spv.Branch ^header                                    llvm.br ^header