diff options
author | Krzysztof Drewniak <Krzysztof.Drewniak@amd.com> | 2023-05-05 22:03:40 +0000 |
---|---|---|
committer | Krzysztof Drewniak <Krzysztof.Drewniak@amd.com> | 2023-05-12 15:57:53 +0000 |
commit | 53a4adc0deb29fcc1f907ea7bc151fdebecf406d (patch) | |
tree | cc0a1a35ffbb09729673309a7d507c9faccc2c19 /llvm/lib/Support/StringRef.cpp | |
parent | 3f6e4e5b6e9451adf0fc21f3c45076d987fbbfd2 (diff) | |
download | llvm-53a4adc0deb29fcc1f907ea7bc151fdebecf406d.zip llvm-53a4adc0deb29fcc1f907ea7bc151fdebecf406d.tar.gz llvm-53a4adc0deb29fcc1f907ea7bc151fdebecf406d.tar.bz2 |
[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
Diffstat (limited to 'llvm/lib/Support/StringRef.cpp')
0 files changed, 0 insertions, 0 deletions