[all-commits] [llvm/llvm-project] 49fa6a: Revert "GlobalISel: Use MMO helper for getting the...

[Matt Arsenault via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 49fa6abf7472022d7bf1fb05df3033a7bd1ff0de
      https://github.com/llvm/llvm-project/commit/49fa6abf7472022d7bf1fb05df3033a7bd1ff0de
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2021-06-29 (Tue, 29 Jun 2021)

  Changed paths:
    M llvm/lib/CodeGen/GlobalISel/LegalizerInfo.cpp

  Log Message:
  -----------
  Revert "GlobalISel: Use MMO helper for getting the size in bits"

This reverts commit dc98adfb448bdb845605185bb173e99614a17790.

This should still be done, but this is currently causing some commit
ordering issues.


  Commit: 990278d026d680942c859be70836ad34a9a716f7
      https://github.com/llvm/llvm-project/commit/990278d026d680942c859be70836ad34a9a716f7
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2021-06-29 (Tue, 29 Jun 2021)

  Changed paths:
    M llvm/include/llvm/CodeGen/MachineFunction.h
    M llvm/include/llvm/CodeGen/MachineMemOperand.h
    M llvm/include/llvm/Support/LowLevelTypeImpl.h
    M llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
    M llvm/lib/CodeGen/GlobalISel/MachineIRBuilder.cpp
    M llvm/lib/CodeGen/LowLevelType.cpp
    M llvm/lib/CodeGen/MachineFunction.cpp
    M llvm/lib/CodeGen/MachineOperand.cpp
    M llvm/lib/Target/AArch64/GISel/AArch64LegalizerInfo.cpp
    M llvm/lib/Target/ARM/ARMCallLowering.cpp
    M llvm/test/CodeGen/AMDGPU/GlobalISel/sdivrem.ll
    M llvm/test/CodeGen/AMDGPU/GlobalISel/udivrem.ll

  Log Message:
  -----------
  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.


Compare: https://github.com/llvm/llvm-project/compare/8d21d5472501...990278d026d6