commit c0ad75e7587d2e08ba2d5c55311b44ce7f9b20e4
author Matt Arsenault <Matthew.Arsenault@amd.com> Thu Feb 13 15:08:59 2020 -0500
committer Matt Arsenault <arsenm2@gmail.com> Tue Mar 10 23:34:10 2020 -0400
tree 59307e9276a9b98abd6c1b149f0d3283074303e0
parent b17a81f8b23b8412c1fa663c9bbe60060a494503

GlobalISel: Don't try to narrow extending loads/trunc store

If the loaded memory size was smaller than the result size, this would
produce out of bounds memory accesses. I'm wondering if we need a
distinct narrow memory legalize action type, since a case I care about
is decomposing a 4-byte unaligned access into 4 extending loads, which
would leave the original result register type. I'm currently awkwardly
using narrowScalar to handle unaligned accesses that need to be split.

llvm/lib/CodeGen/GlobalISel/LegalizerHelper.cpp

diff --git a/llvm/lib/CodeGen/GlobalISel/LegalizerHelper.cpp b/llvm/lib/CodeGen/GlobalISel/LegalizerHelper.cpp
index 9b9985e..6384cc9 100644
--- a/llvm/lib/CodeGen/GlobalISel/LegalizerHelper.cpp
+++ b/llvm/lib/CodeGen/GlobalISel/LegalizerHelper.cpp
@@ -3035,6 +3035,12 @@
   Register AddrReg = MI.getOperand(1).getReg();
   LLT ValTy = MRI.getType(ValReg);
 
+  // FIXME: Do we need a distinct NarrowMemory legalize action?
+  if (ValTy.getSizeInBits() != 8 * MMO->getSize()) {
+    LLVM_DEBUG(dbgs() << "Can't narrow extload/truncstore\n");
+    return UnableToLegalize;
+  }
+
   int NumParts = -1;
   int NumLeftover = -1;
   LLT LeftoverTy;