[all-commits] [llvm/llvm-project] c0ad75: GlobalISel: Don't try to narrow extending loads/tr...

[Matt Arsenault via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: c0ad75e7587d2e08ba2d5c55311b44ce7f9b20e4
      https://github.com/llvm/llvm-project/commit/c0ad75e7587d2e08ba2d5c55311b44ce7f9b20e4
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2020-03-10 (Tue, 10 Mar 2020)

  Changed paths:
    M llvm/lib/CodeGen/GlobalISel/LegalizerHelper.cpp
    M llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-load-constant.mir
    M llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-load-flat.mir
    M llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-load-global.mir
    M llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-load-local.mir
    M llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-load-private.mir
    M llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-store-global.mir

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