openpower/sv/propagation.mdwn

   1 [[!tag standards]]
   2
   3 # SV Context Propagation
   4
   5 [[!toc]]
   6
   7 TODO: add setvl context propagation.
   8
   9 Context Propagation is for a future version of SV
  10
  11 [[sv/svp64]] context is 24 bits long, and Swizzle is 12.  These
  12 are enormous and not sustainable as far as power consumption is
  13 concerned.  Also, there is repetition of the same contexts to different
  14 instructions. An idea therefore is to add a level of indirection that
  15 allows these contexts to be applied to multiple instructions.
  16
  17 The basic principle is to have a suite of 40 indices in a shift register
  18 that indicate one of seven Contexts shall be applied to upcoming 32 bit
  19 v3.0B instructions.  The Least Significant Index in the shift register is
  20 the one that is applied.  One of those indices is 0b000 which indicates
  21 "no prefix applied".
  22
  23 A special instruction in an svp64 context takes a copy of the `RM[0..23]`
  24 bits, alongside a 21 bit suite that indicates up to 20 32 bit instructions
  25 will have that `RM` applied to them, as well as an index to associate
  26 with the `RM`.  If there are already indices set within the shift register
  27 then the new entries are placed after the end of the highest-indexed one.
  28
  29 | 0.5|6.8  | 9.10|11.31|  name   |
  30 | -- | --- | --- | --- | ------- |
  31 | OP |     | MMM |     | ?-Form  |
  32 | OP | idx | 000 | imm |         |
  33
  34 Three different types of contexts are available so far: svp64 RM and
  35 swizzle. Their format is as follows when stored in SPRs:
  36
  37 | 0..3 | 4..7   | 8........31 |  name     |
  38 | ---- | ----   | ----------- | --------- |
  39 | 0000 | 0000   | `RM[0:23]`  |  [[sv/svp64]] RM |
  40 | 0001 | 0 mask | swiz1 swiz2 |  swizzle  |
  41 | 0010 | brev   | sh0-3 ms0-3 |  [Remap](sv/remap)    |
  42 | 0011 | brev   | sh0-3 ms0-3 |  [SubVL Remap](sv/remap)    |
  43
  44 There are 4 64 bit SPRs used for storing Context, and the data is stored
  45 as follows:
  46
  47 * 7 32 bit contexts are stored, each indexed from 0b001 to 0b111,
  48   2 per 64 bit SPR and 1 in the 4th.
  49 * Starting from bit 32 of the 4th SPR, in batches of 40 bits the Shift
  50   Registers are stored.
  51
  52 When each LSB is nonzero in any one of the seven Shift Registers
  53 the corresponding Contexts are looked up and merged (ORed) together.
  54 Contexts for different purposes however may not be mixed: an illegal
  55 instruction is raised if this occurs.
  56
  57 The reason for merging the contexts is so that different aspects may be
  58 applied.  For example some `RM` contexts may indicate that predication
  59 is to be applied to an instruction whilst another context may contain
  60 the svp64 Mode.  Combining the two allows the predication aspect to be
  61 merged and shared, making for better packing.
  62
  63 These changes occur on a precise schedule: compilers should not have
  64 difficulties statically allocating the Context Propagation, as long
  65 as certain conventions are followed, such as avoidance of allowing the
  66 context to propagate through branches used by more than one incoming path,
  67 and variable-length loops.
  68
  69 Loops, clearly, because if the setup of the shift registers does
  70 not precisely match the number of instructions, the meaning of those
  71 instructions will change as the bits in the shift registers run out!
  72 However if the loops are of fixed static size, with no conditional early exit,  and small enough (40 instructions
  73 maximum) then it is perfectly reasonable to insert repeated patterns into
  74 the shift registers, enough to cover all the loops.  Ordinarily however
  75 the use of the Context Propagation instructions should be inside the
  76 loop and it is the responsibility of the compiler and assembler writer
  77 to ensure that the shift registers reach zero before any loop jump-back
  78 point.
  79
  80 ## Pseudocode:
  81
  82 The internal data structures need not precisely match the SPRs.  Here are
  83 some internal datastructures:
  84
  85     bit sreg[7][40] # seven 40 bit shift registers
  86     bit context[7][24]   # seven contexts
  87     int sregoffs[7] # indicator where last bits were placed
  88
  89 The Context Propagation instruction then inserts bits into the selected
  90 stream:
  91
  92     count = 20-count_trailing_zeros(imm)
  93     context[idx] = new_context
  94     start = sregoffs[idx]
  95     sreg[idx][start:start+count] = imm[0:count]
  96     sregoffs[idx] += count
  97
  98 With each shift register being maintained independently the new bits are
  99 dropped in where the last ones end.  To get which one is to be applied
 100 is as follows:
 101
 102     apply_context
 103     for i in range(7):
 104         if sreg[i][0]:
 105             apply_context |= context[i]
 106         sreg[i] = sreg[i] >> 1
 107         sregoffs[i] -= 1
 108
 109 Note that it is the LSB that says which context is to be applied.
 110
 111 # Swizzle Propagation
 112
 113 Swizzle Contexts follow the same schedule except that there is a mask
 114 for specifying to which registers the swizzle is to be applied, and
 115 there is only 17 bit suite to indicate the instructions to which the
 116 swizzle applies.
 117
 118 The bits in the svp64 `RM` field are interpreted as a pair of 12 bit
 119 swizzles
 120
 121 | 0.5| 6.8 | 9.11| 12.14 | 15.31 |  name   |
 122 | -- | --- | --- | ----- | ----- | ------- |
 123 | OP |     | MMM | mask  |       | ?-Form  |
 124 | OP | idx | 001 | mask  |  imm  |         |
 125
 126 Note however that it is only svp64 encoded instructions to which swizzle
 127 applies, so Swizzle Shift Registers only activate (and shift down)
 128 on svp64 instructions. *This includes Context-propagated ones!*
 129
 130 The mask is encoded as follows:
 131
 132 * bit 0 indicates that src1 is swizzled
 133 * bit 1 indicates that src2 is swizzled
 134 * bit 2 indicates that src3 is swizzled
 135
 136 When the compiler creates Swizzle Contexts it is important to recall
 137 that the Contexts will be ORed together. Thus one Context may specify
 138 a mask whilst the other Context specifies the swizzles: ORing different
 139 mask contexts with different swizzle Contexts allows more combinations
 140 than would normally fit into seven Contexts.
 141
 142 More than one bit is permitted to be set in the mask: swiz1 is applied
 143 to the first src operand specified by the mask, and swiz2 is applied to
 144 the second.
 145
 146 # 2D/3D Matrix Remap
 147
 148 [[sv/remap]] allows up to four Vectors (all four arguments of `fma` for example)
 149 to be algorithmically arbitrarily remapped via 1D, 2D or 3D reshaping.
 150 The amount of information needed to do so is however quite large: consequently it is only practical to apply indirectly, via Context propagation.
 151
 152 Vectors may be remapped such that Matrix multiply of any arbitrary size
 153 is performed in one Vectorised `fma` instruction as long as the total
 154 number of elements is less than 64 (maximum for VL).
 155
 156 Additionally, in a fashion known as "Structure Packing" in NEON and RVV, it may be used to perform "zipping" and "unzipping" of
 157 elements in a regular fashion of any arbitrary size and depth: RGB
 158 or Audio channel data may be split into separate contiguous lanes of
 159 registers, for example.
 160
 161 There are four possible Shapes.  Unlike swizzle contexts this one requires
 162 he external remap Shape SPRs because the state information is too large
 163 to fit into the Context itself.  Thus the Remap Context says which Shapes
 164 apply to which registers.
 165
 166 The instruction format is the same as `RM` and thus uses 21 bits of
 167 immediate, 29 of which are dropped into the indexed Shift Register
 168
 169 | 0.5| 6.8 | 9.10| 11.14 | 15.31|  name   |
 170 | -- | --- | --- | ----  | ---- | ------- |
 171 | OP |     | MM  |       |      | ?-Form  |
 172 | OP | idx | 10  | brev  | imm  | Remap        |
 173 | OP | idx | 11  | brev  | imm  | SUBVL Remap    |
 174
 175 SUBVL Remap applies the remapping even into the SUBVL Elements, for a total of `VL\*SUBVL` Elements.  **swizzle may be applied on top as a second phase** after SUBVL Remap.
 176
 177 brev field, which also applied down to SUBVL elements (not to the whole
 178 vec2/3/4, that would be handled by swizzle reordering):
 179
 180 * bit 0 indicates that dest elements are byte-reversed
 181 * bit 1 indicates that src1 elements are byte-reversed
 182 * bit 2 indicates that src2 elements are byte-reversed
 183 * bit 3 indicates that src3 elements are byte-reversed
 184
 185 Again it is the 24 bit `RM` that is interpreted differently:
 186
 187 | 0...7 | 8....23 |
 188 | ----- | ------- |
 189 | sh0-3 | mask0-3 |
 190
 191 The shape indices 0-3 are numbered 0-3 whilst the masks are bitmasks
 192 that indicate src or dest to which the associated shape (0-3) is to
 193 be applied.  A zero mask indicates that the Shape is not to be applied.
 194 Note that whilst the masks are unary encoded the Shape indices sh0-3
 195 are not: this must be taken into consideration when ORing occurs.
 196
 197 The mask is encoded as follows:
 198
 199 * bit 0 indicates that the first svp64 EXTRA field is reshaped
 200 * bit 1 indicates that the second svp64 EXTRA field is reshaped
 201 * bit 2 indicates that the third sv64 EXTRA field is reshaped
 202 * bit 3 indicates that the fourth svp64 EXTRA field reshaped
 203
 204 This allows even instructions that have 2 destination registers to be reshaped.