[PATCH] D21534: GlobalISel: first outline of legalization interface.

[Tim Northover via llvm-commits]

t.p.northover created this revision.
t.p.northover added a reviewer: qcolombet.
t.p.northover added a subscriber: llvm-commits.
t.p.northover set the repository for this revision to rL LLVM.
Herald added subscribers: mcrosier, vkalintiris, mehdi_amini.

This implements a preliminary interface for targets to specify how a given operation should be legalized, with a fewproof of concept legalizations for integer addition.
    
ISelDAG seems to have overloaded "Expand" to mean quite a few different possible legalization strategies, which I'd like to avoid for GlobalISel. So at the moment, the possible generic options are:

  - Legal (nothing to do)
  - NarrowScalar (e.g. i64 -> i32 twice, <4 x i64> -> <4 x i32>).
  - WidenScalar (e.g. i8 -> i32, <8 x i1> -> <8 x i8>).
  - FewerElements (e.g. <4 x i64> -> <2 x i64> twice).
  - MoreElements (e.g. <2 x i8> -> <8 x i8>).
  - Libcall (self-explanatory).
  - Custom (as with ISelDAG, target will handle it).
    
I am hoping scalarization can be considered a special case of "FewerElements" where the legal number of elements is 1 since the distinction between "<1 x %type>" and "%type" that exists now is a bit sketchy.
    
For an operation that is illegal on a vector type, we first legalize the underlying scalar (with a separate "setScalarInVectorAction" interface specifying how because, for example, "G_ADD <8 x i8>" may be fine but "G_ADD i8" only representable by promoting to i64). After that we know that the operation is legal for *some* number of vector elements and the second step is to find that.
    
Some extension will be needed to handle operations with more than one type (for example "i1 = G_ICMP i8 %a, %b"). In this and some other cases what should happen to the result is independent of the operands. I have some vague ideas on this, but nothing concrete.

One other thought, not on the wider picture but the specific G_ADD case in this patch was: just how many G_ADDs do we need/want? For now I've stuck with ADD/ADDC/ADDE, but I'm increasingly convinced that the last two are redundant (ADDC is just "ADDE a, b, 0") and I'm starting to think that it might be better to **just** have ADDE at the MIR level (with G_ADD being "res, thing<dead> = G_ADDE a, b, 0"). We could still have convenience queries and MIRBuilder methods to produce simple adds.

Any bright ideas or other comments welcome!

Cheers.

Tim.

Repository:
  rL LLVM

http://reviews.llvm.org/D21534

Files:
  include/llvm/CodeGen/GlobalISel/GISelAccessor.h
  include/llvm/CodeGen/GlobalISel/LegalizeMachineIR.h
  include/llvm/CodeGen/GlobalISel/MachineIRBuilder.h
  include/llvm/CodeGen/GlobalISel/MachineLegalizeInfo.h
  include/llvm/CodeGen/TargetPassConfig.h
  include/llvm/InitializePasses.h
  include/llvm/Target/GenericOpcodes.td
  include/llvm/Target/TargetOpcodes.def
  include/llvm/Target/TargetSubtargetInfo.h
  lib/CodeGen/GlobalISel/CMakeLists.txt
  lib/CodeGen/GlobalISel/GlobalISel.cpp
  lib/CodeGen/GlobalISel/IRTranslator.cpp
  lib/CodeGen/GlobalISel/LegalizeMachineIR.cpp
  lib/CodeGen/GlobalISel/MachineIRBuilder.cpp
  lib/CodeGen/GlobalISel/MachineLegalizeInfo.cpp
  lib/CodeGen/LLVMTargetMachine.cpp
  lib/Target/AArch64/AArch64MachineLegalizeInfo.cpp
  lib/Target/AArch64/AArch64MachineLegalizeInfo.h
  lib/Target/AArch64/AArch64Subtarget.cpp
  lib/Target/AArch64/AArch64Subtarget.h
  lib/Target/AArch64/AArch64TargetMachine.cpp
  lib/Target/AArch64/CMakeLists.txt
  test/CodeGen/AArch64/GlobalISel/legalize-add.mir
  test/TableGen/trydecode-emission.td
  test/TableGen/trydecode-emission2.td
  test/TableGen/trydecode-emission3.td

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D21534.61299.patch
Type: text/x-patch
Size: 50218 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160620/cac3bb87/attachment.bin>