[all-commits] [llvm/llvm-project] e69916: [AArch64][GlobalISel] Legalize integer across-lane...

[Vladislav Dzhidzhoev via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e69916c9430dcb29fe979111a6103957bfc70d64
      https://github.com/llvm/llvm-project/commit/e69916c9430dcb29fe979111a6103957bfc70d64
  Author: Vladislav Dzhidzhoev <vdzhidzhoev at accesssoftek.com>
  Date:   2023-08-17 (Thu, 17 Aug 2023)

  Changed paths:
    M llvm/lib/Target/AArch64/AArch64InstrFormats.td
    M llvm/lib/Target/AArch64/AArch64InstrGISel.td
    M llvm/lib/Target/AArch64/AArch64InstrInfo.td
    M llvm/lib/Target/AArch64/AArch64RegisterInfo.td
    M llvm/lib/Target/AArch64/GISel/AArch64LegalizerInfo.cpp
    M llvm/lib/Target/AArch64/GISel/AArch64RegisterBankInfo.cpp
    M llvm/test/CodeGen/AArch64/arm64-smaxv.ll
    M llvm/test/CodeGen/AArch64/arm64-sminv.ll
    M llvm/test/CodeGen/AArch64/arm64-umaxv.ll
    M llvm/test/CodeGen/AArch64/arm64-uminv.ll
    M llvm/test/CodeGen/AArch64/arm64-vaddv.ll

  Log Message:
  -----------
  [AArch64][GlobalISel] Legalize integer across-lane intrinsics with actual type

Across-lane intrinsics with integer destination type (uaddv, saddv,
umaxv, smavx, uminv, sminv) were legalized with the destination type
given in the LLVM IR intrinsic’s definition. It was wider than
the actual destination type of the corresponding machine instruction.
InstructionSelect was implicitly supposed to generate underlying
extension instructions for these intrinsics, while the real destination
type was opaque for other GlobalISel passes.  Thus,
llvm/test/CodeGen/AArch64/arm64-vaddv.ll failed on GlobalISel since
the generated code was worse in functions that used the value of
an across-lane intrinsic in following FP&SIMD instructions (functions
with _used_by_laneop suffix).

Here intrinsics are legalized and selected with an actual destination
type, making it transparent to other passes. If the destination
value is used in further instructions accepting FPR registers, there
won’t be extra copies across register banks. i16 type is added to
the list of the types of the FPR16 register bank to make it possible,
and a few SelectionDAG patterns are modified to eliminate ambiguity
in TableGen.

Differential Revision: https://reviews.llvm.org/D156831