[PATCH] D30529: [GlobalISel] Enable specifying how to legalize non-power-of-2 size types.

[Kristof Beyls via Phabricator via llvm-commits]

kristof.beyls created this revision.
Herald added subscribers: tpr, dberris, nhaehnle, arsenm, aemerson.
Herald added a reviewer: javed.absar.

This is a prototype implementation of how it would be possible to specify how
to legalize non-power-of-2 sized types in the GlobalISel Legalizer pass.
Please note that most of the code to do the actual lowering of non-power-of-2
sized types is missing, this is just trying to make it possible for targets to
specify what is legal, and how non-legal types should be legalized.
Probably a lot of further work is needed in the actual legalizing and the other
passes in GlobalISel to support non-power-of-2 sized types.

I hope the documentation in LegalizerInfo.h and the examples provided in the
various {Target}LegalizerInfo.cpp and LegalizerInfoTest.cpp explains well
enough how this is ment to be used.

The basic idea is that a target specifies what to do for all sizes, by mapping
intervals of integers representing a range of size types to an action to take,
e.g.:

  setAction({G_ADD, LLT:scalar(1)},
            {{1, WidenScalar},  // bit sizes [ 1, 31[
             {32, Legal},       // bit sizes [32, 33[
             {33, WidenScalar}, // bit sizes [33, 64[
             {64, Legal},       // bit sizes [64, 65[
             {65, NarrowScalar} // bit sizes [65, +inf[
            });

We could try to invent a nicer syntax than the above to specify this, but for
me the above works well enough, and isn't too horrible.

Another major change is that getAction no longer returns a single action, but
returns a sequence of actions, as legalizing non-power-of-2 types may need
multiple actions. For example: findLegalAction({G_REM, 13}) should return

  [(WidenScalar, 32), (Lower, 32)], indicating to first widen the s13
  scalar to 32 bits, and to then lower it, assuming the setAction on SREM
  was something like:
  setAction({G_REM, LLT:scalar(1)},
            {{1, WidenScalar},  // bit sizes [ 1, 31[
             {32, Lower},       // bit sizes [32, 33[
             {33, NarrowScalar} // bit sizes [65, +inf[
            });

In the existing targets having some support for GlobalIsel, I tried to not
change the semantics of what is defined in setAction at the moment for ARM,
X86 and AMDGPU. For the AArch64 target, I tried to have a few more examples
of how to specify how to legalize non-power-of-2 sized types, to help reviewers
to see a few more examples of how this could work. But before committing, it's
probably best to make non-power-of-2-sized types explicitly marked as
unsupported in AArch64 too, so that in later commits we can incrementally add
support for non-power-of-2-sized types for specific operations or specific
Actions, and make sure the necessary regression tests are covered.

This drops the need for:

- LegalizerInfo::computeTables().
- LLT::{half,double}...Size().

This probably makes legalization slower than before (I didn't try to
measure it), but I'm assuming that by introducing one or a few caches
(see FIXMEs), we can remove most of the overhead.

This is also a little bit behind top-of-trunk.

I'm mainly looking for high-level review to help me progress this to an
acceptable design change and a committable patch. But detailed feedback is of
course also very welcome!


https://reviews.llvm.org/D30529

Files:
  include/llvm/CodeGen/GlobalISel/LegalizerInfo.h
  include/llvm/CodeGen/LowLevelType.h
  lib/CodeGen/GlobalISel/LegalizerHelper.cpp
  lib/CodeGen/GlobalISel/LegalizerInfo.cpp
  lib/Target/AArch64/AArch64LegalizerInfo.cpp
  lib/Target/AMDGPU/AMDGPULegalizerInfo.cpp
  lib/Target/ARM/ARMLegalizerInfo.cpp
  lib/Target/X86/X86LegalizerInfo.cpp
  unittests/CodeGen/GlobalISel/LegalizerInfoTest.cpp
  unittests/CodeGen/LowLevelTypeTest.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D30529.90303.patch
Type: text/x-patch
Size: 67199 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170302/3fad4721/attachment.bin>