[PATCH] D86519: [SystemZ] New pass for domain reassignment from integer to vector.

[Jonas Paulsson via Phabricator via llvm-commits]

jonpa added a comment.

I have performed some experiments that does not seem very beneficial, so I include them here in the patch as a separate file instead of updating the patch itself: F13821013: DomReass.patch <https://reviews.llvm.org/F13821013>

This is what I did:

- LoadAddressReplacer: Check uses of ADDR64/32 register to see if it is really used by a MEMORY operand before deciding it is reassignable or not (as opposed to assuming they never are). (The addresses used by the shift instructions are not used to access memory, but they would not be easily reassigned since the scalar version handles them modulo 64 and the vector element shifts module 'element size'. They have not shown up frequently as a bottleneck either.)

- ExperimentalReplacer: Enabled with -domain-experiments. This is a quick way of enabling conversions for more instructions to evaluate the impact without going through all the steps of making sure the generated code is actually correct (output with this option is incorrect, so only used for debugging).

Results:

- There seemed to be only some rare cases of Load Address. For example 'lg; sllg 8; la 255;  In total just 78 LAs reassigned with this.

- Even if *all* RISBGN would be convertable (which they are probably not), adding this opcode does not give a big change - only 62 RISBGNs were reassigned.

(Only 14 closures are found illegal due to vector lane conflicts, so that is not a factor generally.)

  Legal closures found: 199223
  Reassigned closures:   17286  (~9%)
  
  Closures not possible to reassign at point of query: 200910
  Due to
  Used as address :  74575
  COPY to physreg :  59076
  Crossing a call :  42212
  Any of above    : 145609   (~ 72%)
  
  Other reasons seen at this point, following the above:
  COPY from physreg :  9531
  Compare w/0       :  5502
  Any of above      : 15033  (~ 7%)
  
  CR                :  1719

Conclusions:

Even with reassignment added for Load Address, RISBGN, and INSERT_SUBREG which were the major missing items seen, there is less than 10% of a chance of reassigning a closure at the points where register pressure seems to indicate a need for it.

The reasons for this seems to be that in the majority of the cases, there is either a call, a value used as address or COPY:ed to a physreg that makes reassignment undesireable.

Only closures containing at least one reassignable instruction are included in the counts above. The statistics should probably be taken with a grain of salt, since the algorithm for finding reassignable closures are dictating how this all turns out in the end. For example, the search stops at the point of a non-legal instruction, but if that instruction would have had a converter the closure would have grown further. So generally the illegal closures are smaller and greater in number since non convertable instructions make up dividing points. However, the results look quite similar to the last time around and the conclusions seem to make sense since it is probably exactly around calls and many memory accesses that register pressure is at its highest.

Just 1846 less spill/reload instructions less in total over benchmarks (0.3%), which is not motivation enough for this new pass at least as it looks now.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86519/new/

https://reviews.llvm.org/D86519