[llvm-dev] RegBankSelect complex value mappings

Matt Arsenault via llvm-dev llvm-dev at lists.llvm.org
Wed Dec 19 21:25:01 PST 2018


I’m looking at RegBankSelect’s partially implemented support for deciding to split a value between multiple registers and I’m wondering if it’s actually intended to solve the problem I’m trying to use it for. RegisterBankInfo.h has this example mapping table:
  /// E.g.,
  /// Let say we have a 32-bit add and a <2 x 32-bit> vadd. We
  /// can expand the
  /// <2 x 32-bit> add into 2 x 32-bit add.
  /// Currently the TableGen-like file would look like:
  /// \code
  /// PartialMapping[] = {
  /// /*32-bit add*/ {0, 32, GPR},
  /// /*2x32-bit add*/ {0, 32, GPR}, {0, 32, GPR}, // <-- Same entry 3x
  /// /*<2x32-bit> vadd {0, 64, VPR}
  /// }; // PartialMapping duplicated.
  /// ValueMapping[] {
  ///   /*plain 32-bit add*/ {&PartialMapping[0], 1},
  ///   /*expanded vadd on 2xadd*/ {&PartialMapping[1], 2},
  ///   /*plain <2x32-bit> vadd*/ {&PartialMapping[3], 1}
  /// };

This looks almost like the problem I want to solve for AMDGPU. There are 2 main register banks. On the SALU, some 64-bit operation are available which can only be 32-bit on the VALU. For example, if all of the input operands aren’t in the scalar bank, a 64-bit and needs to be split into 2 32-bit ands. It’s illegal to copy from the vector to the scalar bank, since these don’t mean what vector and scalar mean on other targets.

The current code seems very operand centric and computes costs only based on copies. Decomposing the operation into 2 pieces requires rewriting the entire instruction, not just copying from one offending operand. Is this intended to handle this kind of case, or do I need to introduce a separate register bank aware legalizer pass?


More information about the llvm-dev mailing list