[PATCH] D102869: CodeGen: Store LLT instead of uint64_t in MachineMemOperand

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu May 20 13:34:14 PDT 2021


arsenm created this revision.
arsenm added reviewers: aemerson, paquette, qcolombet, dsanders, aditya_nandakumar, bogner, craig.topper, RKSimon, thegameg, efriedma.
Herald added subscribers: dexonsmith, jfb, hiraditya.
arsenm requested review of this revision.
Herald added a subscriber: wdng.
Herald added a project: LLVM.

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.


https://reviews.llvm.org/D102869

Files:
  llvm/include/llvm/CodeGen/MachineFunction.h
  llvm/include/llvm/CodeGen/MachineMemOperand.h
  llvm/include/llvm/Support/LowLevelTypeImpl.h
  llvm/lib/CodeGen/MachineFunction.cpp
  llvm/lib/CodeGen/MachineOperand.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D102869.346843.patch
Type: text/x-patch
Size: 6769 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210520/33e97bab/attachment.bin>


More information about the llvm-commits mailing list