[all-commits] [llvm/llvm-project] 53a4ad: [AMDGPU] Fix crash with 160-bit p7's by manually d...

[Krzysztof Drewniak via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 53a4adc0deb29fcc1f907ea7bc151fdebecf406d
      https://github.com/llvm/llvm-project/commit/53a4adc0deb29fcc1f907ea7bc151fdebecf406d
  Author: Krzysztof Drewniak <Krzysztof.Drewniak at amd.com>
  Date:   2023-05-12 (Fri, 12 May 2023)

  Changed paths:
    M llvm/lib/Target/AMDGPU/SIISelLowering.cpp
    M llvm/lib/Target/AMDGPU/SIISelLowering.h
    A llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-non-integral-address-spaces-vectors.ll
    A llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-non-integral-address-spaces.ll
    A llvm/test/Transforms/IndVarSimplify/AMDGPU/addrspace-7-doesnt-crash.ll

  Log Message:
  -----------
  [AMDGPU] Fix crash with 160-bit p7's by manually defining getPointerTy

While pointers in address space 7 (128 bit rsrc + 32 bit offset)
should be rewritten out of the code before IR translation on AMDGPU,
higher-level analyses may still call MVT getPointerTy() and the like
on the target machine. Currently, since there is no MVT::i160, this
operation ends up causing crashes.

The changes to the data layout that caused such crashes were D149776.

This patch causes getPointerTy() to return the type MVT::v5i32
and getPointerMemTy() to be MVT::v8i32. These are accurate types,
but mean that we can't use vectors of address space 7 pointers during
codegen. This is mostly OK, since vectors of buffers aren't supported
in LPC anyway, but it's a noticable limitation.

Potential alternative solutions include adjusting getPointerTy() to return
an EVT or adding MVT::i160 and MVT::i256, both of which are rather
disruptive to the rest of the compiler.

Reviewed By: foad

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