]> granicus.if.org Git - llvm/commit
[GlobalISel] Support vector-of-pointers in LLT
authorKristof Beyls <kristof.beyls@arm.com>
Tue, 18 Apr 2017 08:12:45 +0000 (08:12 +0000)
committerKristof Beyls <kristof.beyls@arm.com>
Tue, 18 Apr 2017 08:12:45 +0000 (08:12 +0000)
commitd18725e897b4905e4c25d0b66719d0bb927c33b6
tree3969c976c586fda1f49d5ebe512d0dc64865a396
parent6aff9c901549261c238dcd24473568a3ced9137f
[GlobalISel] Support vector-of-pointers in LLT

This fixes PR32471.

As comment 10 on that bug report highlights
(https://bugs.llvm.org//show_bug.cgi?id=32471#c10), there are quite a
few different defendable design tradeoffs that could be made, including
not representing pointers at all in LLT.

I decided to go for representing vector-of-pointer as a concept in LLT,
while keeping the size of the LLT type 64 bits (this is an increase from
48 bits before). My rationale for keeping pointers explicit is that on
some targets probably it's very handy to have the distinction between
pointer and non-pointer (e.g. 68K has a different register bank for
pointers IIRC). If we keep a scalar pointer, it probably is easiest to
also have a vector-of-pointers to keep LLT relatively conceptually clean
and orthogonal, while we don't have a very strong reason to break that
orthogonality. Once we gain more experience on the use of LLT, we can
of course reconsider this direction.

Rejecting vector-of-pointer types in the IRTranslator is also an option
to avoid the crash reported in PR32471, but that is only a very
short-term solution; also needs quite a bit of code tweaks in places,
and is probably fragile. Therefore I didn't consider this the best
option.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@300535 91177308-0d34-0410-b5e6-96231b3b80d8
include/llvm/Support/LowLevelTypeImpl.h
lib/CodeGen/GlobalISel/MachineIRBuilder.cpp
lib/CodeGen/LowLevelType.cpp
lib/Support/LowLevelType.cpp
lib/Target/AArch64/AArch64RegisterBankInfo.cpp
test/CodeGen/AArch64/GlobalISel/arm64-fallback.ll
unittests/CodeGen/LowLevelTypeTest.cpp