[all-commits] [llvm/llvm-project] 39c55c: GlobalISel: Introduce bitcast legalize action

Matt Arsenault via All-commits all-commits at lists.llvm.org
Tue Mar 24 16:48:04 PDT 2020


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

  Changed paths:
    M llvm/include/llvm/CodeGen/GlobalISel/LegalizerHelper.h
    M llvm/include/llvm/CodeGen/GlobalISel/LegalizerInfo.h
    M llvm/lib/CodeGen/GlobalISel/LegalizerHelper.cpp
    M llvm/lib/CodeGen/GlobalISel/LegalizerInfo.cpp
    M llvm/unittests/CodeGen/GlobalISel/LegalizerHelperTest.cpp
    M llvm/unittests/CodeGen/GlobalISel/LegalizerInfoTest.cpp

  Log Message:
  -----------
  GlobalISel: Introduce bitcast legalize action

For some operations, the type is unimportant and only the number of
bits matters. For example I don't want to treat <4 x s8> as a legal
type, but I also don't want to decompose loads of this into smaller
pieces to get legal register types.

On AMDGPU in SelectionDAG, we legalize a number of operations (most
notably load and store) by coercing all types to vectors of i32. For
GlobalISel, I'm trying very hard to avoid doing this for every type,
but I don't think this strategy can be completely avoided. I'm trying
to avoid bitcasts for any legitimately legal type we can operate on,
since the intervening bitcasts have proven to be a hassle.

For loads, I think I can get away without ever casting the result
type, and handling any arbitrary bitwidth during selection (I will
eventually want new tablegen support to help with this, rather than
having to add every possible type as legal). The unmerge required to
do anything with the value should expand to the expected shifts. This
is trickier for stores, since it would now require handling a wide
array of truncates during selection which I don't want.

Future potentially interesting case are for vector indexing, where
sub-dword type should be indexed in s32 pieces.




More information about the All-commits mailing list