[PATCH] D94091: [AArch64] Add an IR type for the LS64 extension.

[Alexandros Lamprineas via Phabricator via llvm-commits]

labrinea created this revision.
labrinea added reviewers: llvm-commits, t.p.northover, ab, kristof.beyls, simon_tatham.
Herald added a reviewer: deadalnix.
Herald added subscribers: dexonsmith, danielkiss, hiraditya.
labrinea requested review of this revision.
Herald added a project: LLVM.

As explained in the RFC [1], I think we need a new IR type to support the Armv8.7-A LD64B/ST64B instructions in inline assembly. Or, at least, this approach requires the least amount of work. This patch adds a new LLVM IR type named `aarch64_ls64` for representing `data512_t`, which is the C type that ACLE suggests for the corresponding instrinsics.

An obvious alternative would be `i512`, but there is no Machine Value type for it. The integer types in LLVM's enumeration of 'simple value types' only go up to i128, which means both i512 and i256 need to be added because most of the legalization / lowering machinery for integer types assumes that you can find an integer type half the size. But can we legalize those types? The i256 value type doesn't even have a register class to begin with. Even if we manage to just legalize i512 for loads and stores it's not enough. Legitimate IR, which performs arithmetic on i512, would make the compiler crash during instruction selection in the absence of i256:

  define void @foo(i512* %ptr) {
  entry:
      %val = load i512, i512* %ptr, align 8
      %square = mul i512 %val, %val
      store i512 %square, i512* %ptr, align 8
      ret void
  }

Normally you expect that to get automatically broken down into i64 or i32 or whatever the target can cope with.

To give a bit more context about what I've tried with `i512`: I made it a legal type with a valid register class, setting all the operations to 'expand', except for the trivial ones (bitcast and undef), and also load and store. This didn't work well, for most operations, because the in-built code for expanding overlarge integer operations expects to be able to break them into two smaller halves. In the above example that doesn't work, because we've made `i512` a legal type but not `i256`. So the compiler crashes during isel lowering.

Another problem I came across with `i512` was in GlobalISel. It crashes at `-O0` in relation to the new `GPR64x8` register class. The most immediate problem seems to be that `AArch64RegisterBankInfo::getRegBankFromRegClass` doesn't know what register bank that class corresponds to. But even if I workaround it, then further assertions fail beyond it.

[1] http://lists.llvm.org/pipermail/llvm-dev/2020-November/146860.html


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94091

Files:
  llvm/include/llvm-c/Core.h
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/DataLayout.h
  llvm/include/llvm/IR/Type.h
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/AsmWriter.cpp
  llvm/lib/IR/Core.cpp
  llvm/lib/IR/DataLayout.cpp
  llvm/lib/IR/LLVMContextImpl.cpp
  llvm/lib/IR/LLVMContextImpl.h
  llvm/lib/IR/Type.cpp
  llvm/lib/Target/Hexagon/HexagonTargetObjectFile.cpp
  llvm/tools/llvm-c-test/echo.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D94091.314612.patch
Type: text/x-patch
Size: 11445 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210105/750d0669/attachment.bin>