CodeGen: Store LLT instead of uint64_t in MachineMemOperand
authorMatt Arsenault <Matthew.Arsenault@amd.com>
Thu, 20 May 2021 02:06:14 +0000 (22:06 -0400)
committerMatt Arsenault <Matthew.Arsenault@amd.com>
Tue, 29 Jun 2021 21:38:51 +0000 (17:38 -0400)
commit990278d026d680942c859be70836ad34a9a716f7
treef6bdb4f0a9ad4dcf48dc1cf0d6751f9bd9d8c132
parent49fa6abf7472022d7bf1fb05df3033a7bd1ff0de
CodeGen: Store LLT instead of uint64_t in MachineMemOperand

GlobalISel is relying on regular MachineMemOperands to track all of
the memory properties of accesses. Just the raw byte size is
insufficent to disambiguate all situations. For example, if we need to
split an unaligned extending load, we need to know the number of bits
in the original source value and can't infer it from the result
type. This is also a problem for extending vector loads.

This does decrease the maximum representable size from the full
uint64_t bytes to a maximum of 16-bits. No in tree testcases hit this,
other than places using UINT64_MAX for unknown sizes. This may be an
issue for G_MEMCPY and co., although they can just use unknown size
for large static sizes. This also has potential for backend abuse by
relying on the type when it really shouldn't be relevant after
selection.

This does not include the necessary MIR printer/parser changes to
represent this.
12 files changed:
llvm/include/llvm/CodeGen/MachineFunction.h
llvm/include/llvm/CodeGen/MachineMemOperand.h
llvm/include/llvm/Support/LowLevelTypeImpl.h
llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
llvm/lib/CodeGen/GlobalISel/MachineIRBuilder.cpp
llvm/lib/CodeGen/LowLevelType.cpp
llvm/lib/CodeGen/MachineFunction.cpp
llvm/lib/CodeGen/MachineOperand.cpp
llvm/lib/Target/AArch64/GISel/AArch64LegalizerInfo.cpp
llvm/lib/Target/ARM/ARMCallLowering.cpp
llvm/test/CodeGen/AMDGPU/GlobalISel/sdivrem.ll
llvm/test/CodeGen/AMDGPU/GlobalISel/udivrem.ll