2016-10-15 06:18:18 +08:00
|
|
|
//===- AArch64LegalizerInfo.cpp ----------------------------------*- C++ -*-==//
|
2016-07-23 04:03:43 +08:00
|
|
|
//
|
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
|
//
|
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
/// \file
|
|
|
|
|
/// This file implements the targeting of the Machinelegalizer class for
|
|
|
|
|
/// AArch64.
|
|
|
|
|
/// \todo This should be generated by TableGen.
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
2016-10-15 06:18:18 +08:00
|
|
|
#include "AArch64LegalizerInfo.h"
|
2017-11-29 04:21:15 +08:00
|
|
|
#include "AArch64Subtarget.h"
|
2017-06-06 19:49:48 +08:00
|
|
|
#include "llvm/CodeGen/GlobalISel/MachineIRBuilder.h"
|
2017-02-16 07:22:50 +08:00
|
|
|
#include "llvm/CodeGen/MachineInstr.h"
|
|
|
|
|
#include "llvm/CodeGen/MachineRegisterInfo.h"
|
2017-11-17 09:07:10 +08:00
|
|
|
#include "llvm/CodeGen/TargetOpcodes.h"
|
2016-07-23 04:03:43 +08:00
|
|
|
#include "llvm/CodeGen/ValueTypes.h"
|
|
|
|
|
#include "llvm/IR/DerivedTypes.h"
|
2017-06-06 19:49:48 +08:00
|
|
|
#include "llvm/IR/Type.h"
|
2016-07-23 04:03:43 +08:00
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
|
[GlobalISel] Enable legalizing non-power-of-2 sized types.
This changes the interface of how targets describe how to legalize, see
the below description.
1. Interface for targets to describe how to legalize.
In GlobalISel, the API in the LegalizerInfo class is the main interface
for targets to specify which types are legal for which operations, and
what to do to turn illegal type/operation combinations into legal ones.
For each operation the type sizes that can be legalized without having
to change the size of the type are specified with a call to setAction.
This isn't different to how GlobalISel worked before. For example, for a
target that supports 32 and 64 bit adds natively:
for (auto Ty : {s32, s64})
setAction({G_ADD, 0, s32}, Legal);
or for a target that needs a library call for a 32 bit division:
setAction({G_SDIV, s32}, Libcall);
The main conceptual change to the LegalizerInfo API, is in specifying
how to legalize the type sizes for which a change of size is needed. For
example, in the above example, how to specify how all types from i1 to
i8388607 (apart from s32 and s64 which are legal) need to be legalized
and expressed in terms of operations on the available legal sizes
(again, i32 and i64 in this case). Before, the implementation only
allowed specifying power-of-2-sized types (e.g. setAction({G_ADD, 0,
s128}, NarrowScalar). A worse limitation was that if you'd wanted to
specify how to legalize all the sized types as allowed by the LLVM-IR
LangRef, i1 to i8388607, you'd have to call setAction 8388607-3 times
and probably would need a lot of memory to store all of these
specifications.
Instead, the legalization actions that need to change the size of the
type are specified now using a "SizeChangeStrategy". For example:
setLegalizeScalarToDifferentSizeStrategy(
G_ADD, 0, widenToLargerAndNarrowToLargest);
This example indicates that for type sizes for which there is a larger
size that can be legalized towards, do it by Widening the size.
For example, G_ADD on s17 will be legalized by first doing WidenScalar
to make it s32, after which it's legal.
The "NarrowToLargest" indicates what to do if there is no larger size
that can be legalized towards. E.g. G_ADD on s92 will be legalized by
doing NarrowScalar to s64.
Another example, taken from the ARM backend is:
for (unsigned Op : {G_SDIV, G_UDIV}) {
setLegalizeScalarToDifferentSizeStrategy(Op, 0,
widenToLargerTypesUnsupportedOtherwise);
if (ST.hasDivideInARMMode())
setAction({Op, s32}, Legal);
else
setAction({Op, s32}, Libcall);
}
For this example, G_SDIV on s8, on a target without a divide
instruction, would be legalized by first doing action (WidenScalar,
s32), followed by (Libcall, s32).
The same principle is also followed for when the number of vector lanes
on vector data types need to be changed, e.g.:
setAction({G_ADD, LLT::vector(8, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(16, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(8, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(2, 32)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 32)}, LegalizerInfo::Legal);
setLegalizeVectorElementToDifferentSizeStrategy(
G_ADD, 0, widenToLargerTypesUnsupportedOtherwise);
As currently implemented here, vector types are legalized by first
making the vector element size legal, followed by then making the number
of lanes legal. The strategy to follow in the first step is set by a
call to setLegalizeVectorElementToDifferentSizeStrategy, see example
above. The strategy followed in the second step
"moreToWiderTypesAndLessToWidest" (see code for its definition),
indicating that vectors are widened to more elements so they map to
natively supported vector widths, or when there isn't a legal wider
vector, split the vector to map it to the widest vector supported.
Therefore, for the above specification, some example legalizations are:
* getAction({G_ADD, LLT::vector(3, 3)})
returns {WidenScalar, LLT::vector(3, 8)}
* getAction({G_ADD, LLT::vector(3, 8)})
then returns {MoreElements, LLT::vector(8, 8)}
* getAction({G_ADD, LLT::vector(20, 8)})
returns {FewerElements, LLT::vector(16, 8)}
2. Key implementation aspects.
How to legalize a specific (operation, type index, size) tuple is
represented by mapping intervals of integers representing a range of
size types to an action to take, e.g.:
setScalarAction({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[
});
Please note that most of the code to do the actual lowering of
non-power-of-2 sized types is currently 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 quite a bit 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 meant to be used.
This drops the need for LLT::{half,double}...Size().
Differential Revision: https://reviews.llvm.org/D30529
llvm-svn: 317560
2017-11-07 18:34:34 +08:00
|
|
|
/// FIXME: The following static functions are SizeChangeStrategy functions
|
|
|
|
|
/// that are meant to temporarily mimic the behaviour of the old legalization
|
|
|
|
|
/// based on doubling/halving non-legal types as closely as possible. This is
|
|
|
|
|
/// not entirly possible as only legalizing the types that are exactly a power
|
|
|
|
|
/// of 2 times the size of the legal types would require specifying all those
|
|
|
|
|
/// sizes explicitly.
|
|
|
|
|
/// In practice, not specifying those isn't a problem, and the below functions
|
|
|
|
|
/// should disappear quickly as we add support for legalizing non-power-of-2
|
|
|
|
|
/// sized types further.
|
|
|
|
|
static void
|
|
|
|
|
addAndInterleaveWithUnsupported(LegalizerInfo::SizeAndActionsVec &result,
|
|
|
|
|
const LegalizerInfo::SizeAndActionsVec &v) {
|
|
|
|
|
for (unsigned i = 0; i < v.size(); ++i) {
|
|
|
|
|
result.push_back(v[i]);
|
|
|
|
|
if (i + 1 < v[i].first && i + 1 < v.size() &&
|
|
|
|
|
v[i + 1].first != v[i].first + 1)
|
|
|
|
|
result.push_back({v[i].first + 1, LegalizerInfo::Unsupported});
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static LegalizerInfo::SizeAndActionsVec
|
|
|
|
|
widen_1_narrow_128_ToLargest(const LegalizerInfo::SizeAndActionsVec &v) {
|
|
|
|
|
assert(v.size() >= 1);
|
|
|
|
|
assert(v[0].first > 2);
|
|
|
|
|
LegalizerInfo::SizeAndActionsVec result = {{1, LegalizerInfo::WidenScalar},
|
|
|
|
|
{2, LegalizerInfo::Unsupported}};
|
|
|
|
|
addAndInterleaveWithUnsupported(result, v);
|
|
|
|
|
auto Largest = result.back().first;
|
|
|
|
|
assert(Largest + 1 < 128);
|
|
|
|
|
result.push_back({Largest + 1, LegalizerInfo::Unsupported});
|
|
|
|
|
result.push_back({128, LegalizerInfo::NarrowScalar});
|
|
|
|
|
result.push_back({129, LegalizerInfo::Unsupported});
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static LegalizerInfo::SizeAndActionsVec
|
|
|
|
|
widen_16(const LegalizerInfo::SizeAndActionsVec &v) {
|
|
|
|
|
assert(v.size() >= 1);
|
|
|
|
|
assert(v[0].first > 17);
|
|
|
|
|
LegalizerInfo::SizeAndActionsVec result = {{1, LegalizerInfo::Unsupported},
|
|
|
|
|
{16, LegalizerInfo::WidenScalar},
|
|
|
|
|
{17, LegalizerInfo::Unsupported}};
|
|
|
|
|
addAndInterleaveWithUnsupported(result, v);
|
|
|
|
|
auto Largest = result.back().first;
|
|
|
|
|
result.push_back({Largest + 1, LegalizerInfo::Unsupported});
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static LegalizerInfo::SizeAndActionsVec
|
|
|
|
|
widen_1_8(const LegalizerInfo::SizeAndActionsVec &v) {
|
|
|
|
|
assert(v.size() >= 1);
|
|
|
|
|
assert(v[0].first > 9);
|
|
|
|
|
LegalizerInfo::SizeAndActionsVec result = {
|
|
|
|
|
{1, LegalizerInfo::WidenScalar}, {2, LegalizerInfo::Unsupported},
|
|
|
|
|
{8, LegalizerInfo::WidenScalar}, {9, LegalizerInfo::Unsupported}};
|
|
|
|
|
addAndInterleaveWithUnsupported(result, v);
|
|
|
|
|
auto Largest = result.back().first;
|
|
|
|
|
result.push_back({Largest + 1, LegalizerInfo::Unsupported});
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static LegalizerInfo::SizeAndActionsVec
|
|
|
|
|
widen_1_8_16(const LegalizerInfo::SizeAndActionsVec &v) {
|
|
|
|
|
assert(v.size() >= 1);
|
|
|
|
|
assert(v[0].first > 17);
|
|
|
|
|
LegalizerInfo::SizeAndActionsVec result = {
|
|
|
|
|
{1, LegalizerInfo::WidenScalar}, {2, LegalizerInfo::Unsupported},
|
|
|
|
|
{8, LegalizerInfo::WidenScalar}, {9, LegalizerInfo::Unsupported},
|
|
|
|
|
{16, LegalizerInfo::WidenScalar}, {17, LegalizerInfo::Unsupported}};
|
|
|
|
|
addAndInterleaveWithUnsupported(result, v);
|
|
|
|
|
auto Largest = result.back().first;
|
|
|
|
|
result.push_back({Largest + 1, LegalizerInfo::Unsupported});
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static LegalizerInfo::SizeAndActionsVec
|
|
|
|
|
widen_1_8_16_narrowToLargest(const LegalizerInfo::SizeAndActionsVec &v) {
|
|
|
|
|
assert(v.size() >= 1);
|
|
|
|
|
assert(v[0].first > 17);
|
|
|
|
|
LegalizerInfo::SizeAndActionsVec result = {
|
|
|
|
|
{1, LegalizerInfo::WidenScalar}, {2, LegalizerInfo::Unsupported},
|
|
|
|
|
{8, LegalizerInfo::WidenScalar}, {9, LegalizerInfo::Unsupported},
|
|
|
|
|
{16, LegalizerInfo::WidenScalar}, {17, LegalizerInfo::Unsupported}};
|
|
|
|
|
addAndInterleaveWithUnsupported(result, v);
|
|
|
|
|
auto Largest = result.back().first;
|
|
|
|
|
result.push_back({Largest + 1, LegalizerInfo::NarrowScalar});
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static LegalizerInfo::SizeAndActionsVec
|
|
|
|
|
widen_1_8_16_32(const LegalizerInfo::SizeAndActionsVec &v) {
|
|
|
|
|
assert(v.size() >= 1);
|
|
|
|
|
assert(v[0].first > 33);
|
|
|
|
|
LegalizerInfo::SizeAndActionsVec result = {
|
|
|
|
|
{1, LegalizerInfo::WidenScalar}, {2, LegalizerInfo::Unsupported},
|
|
|
|
|
{8, LegalizerInfo::WidenScalar}, {9, LegalizerInfo::Unsupported},
|
|
|
|
|
{16, LegalizerInfo::WidenScalar}, {17, LegalizerInfo::Unsupported},
|
|
|
|
|
{32, LegalizerInfo::WidenScalar}, {33, LegalizerInfo::Unsupported}};
|
|
|
|
|
addAndInterleaveWithUnsupported(result, v);
|
|
|
|
|
auto Largest = result.back().first;
|
|
|
|
|
result.push_back({Largest + 1, LegalizerInfo::Unsupported});
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-29 04:21:15 +08:00
|
|
|
AArch64LegalizerInfo::AArch64LegalizerInfo(const AArch64Subtarget &ST) {
|
2016-08-02 23:10:28 +08:00
|
|
|
using namespace TargetOpcode;
|
2016-09-15 17:20:34 +08:00
|
|
|
const LLT p0 = LLT::pointer(0, 64);
|
2016-08-20 06:40:00 +08:00
|
|
|
const LLT s1 = LLT::scalar(1);
|
2016-08-05 04:54:13 +08:00
|
|
|
const LLT s8 = LLT::scalar(8);
|
|
|
|
|
const LLT s16 = LLT::scalar(16);
|
2016-08-02 23:10:28 +08:00
|
|
|
const LLT s32 = LLT::scalar(32);
|
|
|
|
|
const LLT s64 = LLT::scalar(64);
|
2017-10-17 06:28:27 +08:00
|
|
|
const LLT s128 = LLT::scalar(128);
|
2016-08-02 23:10:28 +08:00
|
|
|
const LLT v2s32 = LLT::vector(2, 32);
|
|
|
|
|
const LLT v4s32 = LLT::vector(4, 32);
|
|
|
|
|
const LLT v2s64 = LLT::vector(2, 64);
|
|
|
|
|
|
2017-07-01 04:27:36 +08:00
|
|
|
for (auto Ty : {p0, s1, s8, s16, s32, s64})
|
|
|
|
|
setAction({G_IMPLICIT_DEF, Ty}, Legal);
|
|
|
|
|
|
2017-10-08 23:29:11 +08:00
|
|
|
for (auto Ty : {s16, s32, s64, p0})
|
2017-08-24 04:45:48 +08:00
|
|
|
setAction({G_PHI, Ty}, Legal);
|
|
|
|
|
|
[GlobalISel] Enable legalizing non-power-of-2 sized types.
This changes the interface of how targets describe how to legalize, see
the below description.
1. Interface for targets to describe how to legalize.
In GlobalISel, the API in the LegalizerInfo class is the main interface
for targets to specify which types are legal for which operations, and
what to do to turn illegal type/operation combinations into legal ones.
For each operation the type sizes that can be legalized without having
to change the size of the type are specified with a call to setAction.
This isn't different to how GlobalISel worked before. For example, for a
target that supports 32 and 64 bit adds natively:
for (auto Ty : {s32, s64})
setAction({G_ADD, 0, s32}, Legal);
or for a target that needs a library call for a 32 bit division:
setAction({G_SDIV, s32}, Libcall);
The main conceptual change to the LegalizerInfo API, is in specifying
how to legalize the type sizes for which a change of size is needed. For
example, in the above example, how to specify how all types from i1 to
i8388607 (apart from s32 and s64 which are legal) need to be legalized
and expressed in terms of operations on the available legal sizes
(again, i32 and i64 in this case). Before, the implementation only
allowed specifying power-of-2-sized types (e.g. setAction({G_ADD, 0,
s128}, NarrowScalar). A worse limitation was that if you'd wanted to
specify how to legalize all the sized types as allowed by the LLVM-IR
LangRef, i1 to i8388607, you'd have to call setAction 8388607-3 times
and probably would need a lot of memory to store all of these
specifications.
Instead, the legalization actions that need to change the size of the
type are specified now using a "SizeChangeStrategy". For example:
setLegalizeScalarToDifferentSizeStrategy(
G_ADD, 0, widenToLargerAndNarrowToLargest);
This example indicates that for type sizes for which there is a larger
size that can be legalized towards, do it by Widening the size.
For example, G_ADD on s17 will be legalized by first doing WidenScalar
to make it s32, after which it's legal.
The "NarrowToLargest" indicates what to do if there is no larger size
that can be legalized towards. E.g. G_ADD on s92 will be legalized by
doing NarrowScalar to s64.
Another example, taken from the ARM backend is:
for (unsigned Op : {G_SDIV, G_UDIV}) {
setLegalizeScalarToDifferentSizeStrategy(Op, 0,
widenToLargerTypesUnsupportedOtherwise);
if (ST.hasDivideInARMMode())
setAction({Op, s32}, Legal);
else
setAction({Op, s32}, Libcall);
}
For this example, G_SDIV on s8, on a target without a divide
instruction, would be legalized by first doing action (WidenScalar,
s32), followed by (Libcall, s32).
The same principle is also followed for when the number of vector lanes
on vector data types need to be changed, e.g.:
setAction({G_ADD, LLT::vector(8, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(16, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(8, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(2, 32)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 32)}, LegalizerInfo::Legal);
setLegalizeVectorElementToDifferentSizeStrategy(
G_ADD, 0, widenToLargerTypesUnsupportedOtherwise);
As currently implemented here, vector types are legalized by first
making the vector element size legal, followed by then making the number
of lanes legal. The strategy to follow in the first step is set by a
call to setLegalizeVectorElementToDifferentSizeStrategy, see example
above. The strategy followed in the second step
"moreToWiderTypesAndLessToWidest" (see code for its definition),
indicating that vectors are widened to more elements so they map to
natively supported vector widths, or when there isn't a legal wider
vector, split the vector to map it to the widest vector supported.
Therefore, for the above specification, some example legalizations are:
* getAction({G_ADD, LLT::vector(3, 3)})
returns {WidenScalar, LLT::vector(3, 8)}
* getAction({G_ADD, LLT::vector(3, 8)})
then returns {MoreElements, LLT::vector(8, 8)}
* getAction({G_ADD, LLT::vector(20, 8)})
returns {FewerElements, LLT::vector(16, 8)}
2. Key implementation aspects.
How to legalize a specific (operation, type index, size) tuple is
represented by mapping intervals of integers representing a range of
size types to an action to take, e.g.:
setScalarAction({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[
});
Please note that most of the code to do the actual lowering of
non-power-of-2 sized types is currently 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 quite a bit 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 meant to be used.
This drops the need for LLT::{half,double}...Size().
Differential Revision: https://reviews.llvm.org/D30529
llvm-svn: 317560
2017-11-07 18:34:34 +08:00
|
|
|
setLegalizeScalarToDifferentSizeStrategy(G_PHI, 0, widen_1_8);
|
2017-08-25 12:57:27 +08:00
|
|
|
|
2017-09-19 22:25:15 +08:00
|
|
|
for (auto Ty : { s32, s64 })
|
|
|
|
|
setAction({G_BSWAP, Ty}, Legal);
|
|
|
|
|
|
2017-01-27 09:13:30 +08:00
|
|
|
for (unsigned BinOp : {G_ADD, G_SUB, G_MUL, G_AND, G_OR, G_XOR, G_SHL}) {
|
2016-08-26 01:37:39 +08:00
|
|
|
// These operations naturally get the right answer when used on
|
|
|
|
|
// GPR32, even if the actual type is narrower.
|
[AArch64][GlobalISel] Legalize narrow scalar ops again.
Since r279760, we've been marking as legal operations on narrow integer
types that have wider legal equivalents (for instance, G_ADD s8).
Compared to legalizing these operations, this reduced the amount of
extends/truncates required, but was always a weird legalization decision
made at selection time.
So far, we haven't been able to formalize it in a way that permits the
selector generated from SelectionDAG patterns to be sufficient.
Using a wide instruction (say, s64), when a narrower instruction exists
(s32) would introduce register class incompatibilities (when one narrow
generic instruction is selected to the wider variant, but another is
selected to the narrower variant).
It's also impractical to limit which narrow operations are matched for
which instruction, as restricting "narrow selection" to ranges of types
clashes with potentially incompatible instruction predicates.
Concerns were also raised regarding MIPS64's sign-extended register
assumptions, as well as wrapping behavior.
See discussions in https://reviews.llvm.org/D26878.
Instead, legalize the operations.
Should we ever revert to selecting these narrow operations, we should
try to represent this more accurately: for instance, by separating
a "concrete" type on operations, and an "underlying" type on vregs, we
could move the "this narrow-looking op is really legal" decision to the
legalizer, and let the selector use the "underlying" vreg type only,
which would be guaranteed to map to a register class.
In any case, we eventually should mitigate:
- the performance impact by selecting no-op extract/truncates to COPYs
(which we currently do), and the COPYs to register reuses (which we
don't do yet).
- the compile-time impact by optimizing away extract/truncate sequences
in the legalizer.
llvm-svn: 292827
2017-01-24 05:10:05 +08:00
|
|
|
for (auto Ty : {s32, s64, v2s32, v4s32, v2s64})
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({BinOp, Ty}, Legal);
|
[AArch64][GlobalISel] Legalize narrow scalar ops again.
Since r279760, we've been marking as legal operations on narrow integer
types that have wider legal equivalents (for instance, G_ADD s8).
Compared to legalizing these operations, this reduced the amount of
extends/truncates required, but was always a weird legalization decision
made at selection time.
So far, we haven't been able to formalize it in a way that permits the
selector generated from SelectionDAG patterns to be sufficient.
Using a wide instruction (say, s64), when a narrower instruction exists
(s32) would introduce register class incompatibilities (when one narrow
generic instruction is selected to the wider variant, but another is
selected to the narrower variant).
It's also impractical to limit which narrow operations are matched for
which instruction, as restricting "narrow selection" to ranges of types
clashes with potentially incompatible instruction predicates.
Concerns were also raised regarding MIPS64's sign-extended register
assumptions, as well as wrapping behavior.
See discussions in https://reviews.llvm.org/D26878.
Instead, legalize the operations.
Should we ever revert to selecting these narrow operations, we should
try to represent this more accurately: for instance, by separating
a "concrete" type on operations, and an "underlying" type on vregs, we
could move the "this narrow-looking op is really legal" decision to the
legalizer, and let the selector use the "underlying" vreg type only,
which would be guaranteed to map to a register class.
In any case, we eventually should mitigate:
- the performance impact by selecting no-op extract/truncates to COPYs
(which we currently do), and the COPYs to register reuses (which we
don't do yet).
- the compile-time impact by optimizing away extract/truncate sequences
in the legalizer.
llvm-svn: 292827
2017-01-24 05:10:05 +08:00
|
|
|
|
[GlobalISel] Enable legalizing non-power-of-2 sized types.
This changes the interface of how targets describe how to legalize, see
the below description.
1. Interface for targets to describe how to legalize.
In GlobalISel, the API in the LegalizerInfo class is the main interface
for targets to specify which types are legal for which operations, and
what to do to turn illegal type/operation combinations into legal ones.
For each operation the type sizes that can be legalized without having
to change the size of the type are specified with a call to setAction.
This isn't different to how GlobalISel worked before. For example, for a
target that supports 32 and 64 bit adds natively:
for (auto Ty : {s32, s64})
setAction({G_ADD, 0, s32}, Legal);
or for a target that needs a library call for a 32 bit division:
setAction({G_SDIV, s32}, Libcall);
The main conceptual change to the LegalizerInfo API, is in specifying
how to legalize the type sizes for which a change of size is needed. For
example, in the above example, how to specify how all types from i1 to
i8388607 (apart from s32 and s64 which are legal) need to be legalized
and expressed in terms of operations on the available legal sizes
(again, i32 and i64 in this case). Before, the implementation only
allowed specifying power-of-2-sized types (e.g. setAction({G_ADD, 0,
s128}, NarrowScalar). A worse limitation was that if you'd wanted to
specify how to legalize all the sized types as allowed by the LLVM-IR
LangRef, i1 to i8388607, you'd have to call setAction 8388607-3 times
and probably would need a lot of memory to store all of these
specifications.
Instead, the legalization actions that need to change the size of the
type are specified now using a "SizeChangeStrategy". For example:
setLegalizeScalarToDifferentSizeStrategy(
G_ADD, 0, widenToLargerAndNarrowToLargest);
This example indicates that for type sizes for which there is a larger
size that can be legalized towards, do it by Widening the size.
For example, G_ADD on s17 will be legalized by first doing WidenScalar
to make it s32, after which it's legal.
The "NarrowToLargest" indicates what to do if there is no larger size
that can be legalized towards. E.g. G_ADD on s92 will be legalized by
doing NarrowScalar to s64.
Another example, taken from the ARM backend is:
for (unsigned Op : {G_SDIV, G_UDIV}) {
setLegalizeScalarToDifferentSizeStrategy(Op, 0,
widenToLargerTypesUnsupportedOtherwise);
if (ST.hasDivideInARMMode())
setAction({Op, s32}, Legal);
else
setAction({Op, s32}, Libcall);
}
For this example, G_SDIV on s8, on a target without a divide
instruction, would be legalized by first doing action (WidenScalar,
s32), followed by (Libcall, s32).
The same principle is also followed for when the number of vector lanes
on vector data types need to be changed, e.g.:
setAction({G_ADD, LLT::vector(8, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(16, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(8, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(2, 32)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 32)}, LegalizerInfo::Legal);
setLegalizeVectorElementToDifferentSizeStrategy(
G_ADD, 0, widenToLargerTypesUnsupportedOtherwise);
As currently implemented here, vector types are legalized by first
making the vector element size legal, followed by then making the number
of lanes legal. The strategy to follow in the first step is set by a
call to setLegalizeVectorElementToDifferentSizeStrategy, see example
above. The strategy followed in the second step
"moreToWiderTypesAndLessToWidest" (see code for its definition),
indicating that vectors are widened to more elements so they map to
natively supported vector widths, or when there isn't a legal wider
vector, split the vector to map it to the widest vector supported.
Therefore, for the above specification, some example legalizations are:
* getAction({G_ADD, LLT::vector(3, 3)})
returns {WidenScalar, LLT::vector(3, 8)}
* getAction({G_ADD, LLT::vector(3, 8)})
then returns {MoreElements, LLT::vector(8, 8)}
* getAction({G_ADD, LLT::vector(20, 8)})
returns {FewerElements, LLT::vector(16, 8)}
2. Key implementation aspects.
How to legalize a specific (operation, type index, size) tuple is
represented by mapping intervals of integers representing a range of
size types to an action to take, e.g.:
setScalarAction({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[
});
Please note that most of the code to do the actual lowering of
non-power-of-2 sized types is currently 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 quite a bit 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 meant to be used.
This drops the need for LLT::{half,double}...Size().
Differential Revision: https://reviews.llvm.org/D30529
llvm-svn: 317560
2017-11-07 18:34:34 +08:00
|
|
|
if (BinOp != G_ADD)
|
|
|
|
|
setLegalizeScalarToDifferentSizeStrategy(BinOp, 0,
|
|
|
|
|
widen_1_8_16_narrowToLargest);
|
2016-08-05 04:54:13 +08:00
|
|
|
}
|
|
|
|
|
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({G_GEP, p0}, Legal);
|
|
|
|
|
setAction({G_GEP, 1, s64}, Legal);
|
2016-09-15 19:02:19 +08:00
|
|
|
|
[GlobalISel] Enable legalizing non-power-of-2 sized types.
This changes the interface of how targets describe how to legalize, see
the below description.
1. Interface for targets to describe how to legalize.
In GlobalISel, the API in the LegalizerInfo class is the main interface
for targets to specify which types are legal for which operations, and
what to do to turn illegal type/operation combinations into legal ones.
For each operation the type sizes that can be legalized without having
to change the size of the type are specified with a call to setAction.
This isn't different to how GlobalISel worked before. For example, for a
target that supports 32 and 64 bit adds natively:
for (auto Ty : {s32, s64})
setAction({G_ADD, 0, s32}, Legal);
or for a target that needs a library call for a 32 bit division:
setAction({G_SDIV, s32}, Libcall);
The main conceptual change to the LegalizerInfo API, is in specifying
how to legalize the type sizes for which a change of size is needed. For
example, in the above example, how to specify how all types from i1 to
i8388607 (apart from s32 and s64 which are legal) need to be legalized
and expressed in terms of operations on the available legal sizes
(again, i32 and i64 in this case). Before, the implementation only
allowed specifying power-of-2-sized types (e.g. setAction({G_ADD, 0,
s128}, NarrowScalar). A worse limitation was that if you'd wanted to
specify how to legalize all the sized types as allowed by the LLVM-IR
LangRef, i1 to i8388607, you'd have to call setAction 8388607-3 times
and probably would need a lot of memory to store all of these
specifications.
Instead, the legalization actions that need to change the size of the
type are specified now using a "SizeChangeStrategy". For example:
setLegalizeScalarToDifferentSizeStrategy(
G_ADD, 0, widenToLargerAndNarrowToLargest);
This example indicates that for type sizes for which there is a larger
size that can be legalized towards, do it by Widening the size.
For example, G_ADD on s17 will be legalized by first doing WidenScalar
to make it s32, after which it's legal.
The "NarrowToLargest" indicates what to do if there is no larger size
that can be legalized towards. E.g. G_ADD on s92 will be legalized by
doing NarrowScalar to s64.
Another example, taken from the ARM backend is:
for (unsigned Op : {G_SDIV, G_UDIV}) {
setLegalizeScalarToDifferentSizeStrategy(Op, 0,
widenToLargerTypesUnsupportedOtherwise);
if (ST.hasDivideInARMMode())
setAction({Op, s32}, Legal);
else
setAction({Op, s32}, Libcall);
}
For this example, G_SDIV on s8, on a target without a divide
instruction, would be legalized by first doing action (WidenScalar,
s32), followed by (Libcall, s32).
The same principle is also followed for when the number of vector lanes
on vector data types need to be changed, e.g.:
setAction({G_ADD, LLT::vector(8, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(16, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(8, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(2, 32)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 32)}, LegalizerInfo::Legal);
setLegalizeVectorElementToDifferentSizeStrategy(
G_ADD, 0, widenToLargerTypesUnsupportedOtherwise);
As currently implemented here, vector types are legalized by first
making the vector element size legal, followed by then making the number
of lanes legal. The strategy to follow in the first step is set by a
call to setLegalizeVectorElementToDifferentSizeStrategy, see example
above. The strategy followed in the second step
"moreToWiderTypesAndLessToWidest" (see code for its definition),
indicating that vectors are widened to more elements so they map to
natively supported vector widths, or when there isn't a legal wider
vector, split the vector to map it to the widest vector supported.
Therefore, for the above specification, some example legalizations are:
* getAction({G_ADD, LLT::vector(3, 3)})
returns {WidenScalar, LLT::vector(3, 8)}
* getAction({G_ADD, LLT::vector(3, 8)})
then returns {MoreElements, LLT::vector(8, 8)}
* getAction({G_ADD, LLT::vector(20, 8)})
returns {FewerElements, LLT::vector(16, 8)}
2. Key implementation aspects.
How to legalize a specific (operation, type index, size) tuple is
represented by mapping intervals of integers representing a range of
size types to an action to take, e.g.:
setScalarAction({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[
});
Please note that most of the code to do the actual lowering of
non-power-of-2 sized types is currently 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 quite a bit 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 meant to be used.
This drops the need for LLT::{half,double}...Size().
Differential Revision: https://reviews.llvm.org/D30529
llvm-svn: 317560
2017-11-07 18:34:34 +08:00
|
|
|
setLegalizeScalarToDifferentSizeStrategy(G_GEP, 1, widen_1_8_16_32);
|
2016-09-15 19:02:19 +08:00
|
|
|
|
2017-02-15 04:56:29 +08:00
|
|
|
setAction({G_PTR_MASK, p0}, Legal);
|
|
|
|
|
|
2017-01-27 09:13:30 +08:00
|
|
|
for (unsigned BinOp : {G_LSHR, G_ASHR, G_SDIV, G_UDIV}) {
|
2016-08-16 22:02:47 +08:00
|
|
|
for (auto Ty : {s32, s64})
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({BinOp, Ty}, Legal);
|
2016-08-16 22:02:47 +08:00
|
|
|
|
[GlobalISel] Enable legalizing non-power-of-2 sized types.
This changes the interface of how targets describe how to legalize, see
the below description.
1. Interface for targets to describe how to legalize.
In GlobalISel, the API in the LegalizerInfo class is the main interface
for targets to specify which types are legal for which operations, and
what to do to turn illegal type/operation combinations into legal ones.
For each operation the type sizes that can be legalized without having
to change the size of the type are specified with a call to setAction.
This isn't different to how GlobalISel worked before. For example, for a
target that supports 32 and 64 bit adds natively:
for (auto Ty : {s32, s64})
setAction({G_ADD, 0, s32}, Legal);
or for a target that needs a library call for a 32 bit division:
setAction({G_SDIV, s32}, Libcall);
The main conceptual change to the LegalizerInfo API, is in specifying
how to legalize the type sizes for which a change of size is needed. For
example, in the above example, how to specify how all types from i1 to
i8388607 (apart from s32 and s64 which are legal) need to be legalized
and expressed in terms of operations on the available legal sizes
(again, i32 and i64 in this case). Before, the implementation only
allowed specifying power-of-2-sized types (e.g. setAction({G_ADD, 0,
s128}, NarrowScalar). A worse limitation was that if you'd wanted to
specify how to legalize all the sized types as allowed by the LLVM-IR
LangRef, i1 to i8388607, you'd have to call setAction 8388607-3 times
and probably would need a lot of memory to store all of these
specifications.
Instead, the legalization actions that need to change the size of the
type are specified now using a "SizeChangeStrategy". For example:
setLegalizeScalarToDifferentSizeStrategy(
G_ADD, 0, widenToLargerAndNarrowToLargest);
This example indicates that for type sizes for which there is a larger
size that can be legalized towards, do it by Widening the size.
For example, G_ADD on s17 will be legalized by first doing WidenScalar
to make it s32, after which it's legal.
The "NarrowToLargest" indicates what to do if there is no larger size
that can be legalized towards. E.g. G_ADD on s92 will be legalized by
doing NarrowScalar to s64.
Another example, taken from the ARM backend is:
for (unsigned Op : {G_SDIV, G_UDIV}) {
setLegalizeScalarToDifferentSizeStrategy(Op, 0,
widenToLargerTypesUnsupportedOtherwise);
if (ST.hasDivideInARMMode())
setAction({Op, s32}, Legal);
else
setAction({Op, s32}, Libcall);
}
For this example, G_SDIV on s8, on a target without a divide
instruction, would be legalized by first doing action (WidenScalar,
s32), followed by (Libcall, s32).
The same principle is also followed for when the number of vector lanes
on vector data types need to be changed, e.g.:
setAction({G_ADD, LLT::vector(8, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(16, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(8, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(2, 32)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 32)}, LegalizerInfo::Legal);
setLegalizeVectorElementToDifferentSizeStrategy(
G_ADD, 0, widenToLargerTypesUnsupportedOtherwise);
As currently implemented here, vector types are legalized by first
making the vector element size legal, followed by then making the number
of lanes legal. The strategy to follow in the first step is set by a
call to setLegalizeVectorElementToDifferentSizeStrategy, see example
above. The strategy followed in the second step
"moreToWiderTypesAndLessToWidest" (see code for its definition),
indicating that vectors are widened to more elements so they map to
natively supported vector widths, or when there isn't a legal wider
vector, split the vector to map it to the widest vector supported.
Therefore, for the above specification, some example legalizations are:
* getAction({G_ADD, LLT::vector(3, 3)})
returns {WidenScalar, LLT::vector(3, 8)}
* getAction({G_ADD, LLT::vector(3, 8)})
then returns {MoreElements, LLT::vector(8, 8)}
* getAction({G_ADD, LLT::vector(20, 8)})
returns {FewerElements, LLT::vector(16, 8)}
2. Key implementation aspects.
How to legalize a specific (operation, type index, size) tuple is
represented by mapping intervals of integers representing a range of
size types to an action to take, e.g.:
setScalarAction({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[
});
Please note that most of the code to do the actual lowering of
non-power-of-2 sized types is currently 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 quite a bit 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 meant to be used.
This drops the need for LLT::{half,double}...Size().
Differential Revision: https://reviews.llvm.org/D30529
llvm-svn: 317560
2017-11-07 18:34:34 +08:00
|
|
|
setLegalizeScalarToDifferentSizeStrategy(BinOp, 0, widen_1_8_16);
|
2016-08-27 01:46:06 +08:00
|
|
|
}
|
|
|
|
|
|
2017-01-27 09:13:30 +08:00
|
|
|
for (unsigned BinOp : {G_SREM, G_UREM})
|
2016-08-27 01:46:13 +08:00
|
|
|
for (auto Ty : { s1, s8, s16, s32, s64 })
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({BinOp, Ty}, Lower);
|
2016-08-27 01:46:13 +08:00
|
|
|
|
[GlobalISel] Enable legalizing non-power-of-2 sized types.
This changes the interface of how targets describe how to legalize, see
the below description.
1. Interface for targets to describe how to legalize.
In GlobalISel, the API in the LegalizerInfo class is the main interface
for targets to specify which types are legal for which operations, and
what to do to turn illegal type/operation combinations into legal ones.
For each operation the type sizes that can be legalized without having
to change the size of the type are specified with a call to setAction.
This isn't different to how GlobalISel worked before. For example, for a
target that supports 32 and 64 bit adds natively:
for (auto Ty : {s32, s64})
setAction({G_ADD, 0, s32}, Legal);
or for a target that needs a library call for a 32 bit division:
setAction({G_SDIV, s32}, Libcall);
The main conceptual change to the LegalizerInfo API, is in specifying
how to legalize the type sizes for which a change of size is needed. For
example, in the above example, how to specify how all types from i1 to
i8388607 (apart from s32 and s64 which are legal) need to be legalized
and expressed in terms of operations on the available legal sizes
(again, i32 and i64 in this case). Before, the implementation only
allowed specifying power-of-2-sized types (e.g. setAction({G_ADD, 0,
s128}, NarrowScalar). A worse limitation was that if you'd wanted to
specify how to legalize all the sized types as allowed by the LLVM-IR
LangRef, i1 to i8388607, you'd have to call setAction 8388607-3 times
and probably would need a lot of memory to store all of these
specifications.
Instead, the legalization actions that need to change the size of the
type are specified now using a "SizeChangeStrategy". For example:
setLegalizeScalarToDifferentSizeStrategy(
G_ADD, 0, widenToLargerAndNarrowToLargest);
This example indicates that for type sizes for which there is a larger
size that can be legalized towards, do it by Widening the size.
For example, G_ADD on s17 will be legalized by first doing WidenScalar
to make it s32, after which it's legal.
The "NarrowToLargest" indicates what to do if there is no larger size
that can be legalized towards. E.g. G_ADD on s92 will be legalized by
doing NarrowScalar to s64.
Another example, taken from the ARM backend is:
for (unsigned Op : {G_SDIV, G_UDIV}) {
setLegalizeScalarToDifferentSizeStrategy(Op, 0,
widenToLargerTypesUnsupportedOtherwise);
if (ST.hasDivideInARMMode())
setAction({Op, s32}, Legal);
else
setAction({Op, s32}, Libcall);
}
For this example, G_SDIV on s8, on a target without a divide
instruction, would be legalized by first doing action (WidenScalar,
s32), followed by (Libcall, s32).
The same principle is also followed for when the number of vector lanes
on vector data types need to be changed, e.g.:
setAction({G_ADD, LLT::vector(8, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(16, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(8, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(2, 32)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 32)}, LegalizerInfo::Legal);
setLegalizeVectorElementToDifferentSizeStrategy(
G_ADD, 0, widenToLargerTypesUnsupportedOtherwise);
As currently implemented here, vector types are legalized by first
making the vector element size legal, followed by then making the number
of lanes legal. The strategy to follow in the first step is set by a
call to setLegalizeVectorElementToDifferentSizeStrategy, see example
above. The strategy followed in the second step
"moreToWiderTypesAndLessToWidest" (see code for its definition),
indicating that vectors are widened to more elements so they map to
natively supported vector widths, or when there isn't a legal wider
vector, split the vector to map it to the widest vector supported.
Therefore, for the above specification, some example legalizations are:
* getAction({G_ADD, LLT::vector(3, 3)})
returns {WidenScalar, LLT::vector(3, 8)}
* getAction({G_ADD, LLT::vector(3, 8)})
then returns {MoreElements, LLT::vector(8, 8)}
* getAction({G_ADD, LLT::vector(20, 8)})
returns {FewerElements, LLT::vector(16, 8)}
2. Key implementation aspects.
How to legalize a specific (operation, type index, size) tuple is
represented by mapping intervals of integers representing a range of
size types to an action to take, e.g.:
setScalarAction({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[
});
Please note that most of the code to do the actual lowering of
non-power-of-2 sized types is currently 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 quite a bit 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 meant to be used.
This drops the need for LLT::{half,double}...Size().
Differential Revision: https://reviews.llvm.org/D30529
llvm-svn: 317560
2017-11-07 18:34:34 +08:00
|
|
|
for (unsigned Op : {G_SMULO, G_UMULO}) {
|
|
|
|
|
setAction({Op, 0, s64}, Lower);
|
|
|
|
|
setAction({Op, 1, s1}, Legal);
|
|
|
|
|
}
|
2017-02-09 05:22:15 +08:00
|
|
|
|
|
|
|
|
for (unsigned Op : {G_UADDE, G_USUBE, G_SADDO, G_SSUBO, G_SMULH, G_UMULH}) {
|
2016-08-26 01:37:32 +08:00
|
|
|
for (auto Ty : { s32, s64 })
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({Op, Ty}, Legal);
|
2016-08-26 01:37:32 +08:00
|
|
|
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({Op, 1, s1}, Legal);
|
2016-08-26 01:37:41 +08:00
|
|
|
}
|
|
|
|
|
|
2017-07-18 22:10:07 +08:00
|
|
|
for (unsigned BinOp : {G_FADD, G_FSUB, G_FMA, G_FMUL, G_FDIV})
|
2016-08-19 00:05:11 +08:00
|
|
|
for (auto Ty : {s32, s64})
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({BinOp, Ty}, Legal);
|
2016-08-19 00:05:11 +08:00
|
|
|
|
2017-02-09 07:23:39 +08:00
|
|
|
for (unsigned BinOp : {G_FREM, G_FPOW}) {
|
|
|
|
|
setAction({BinOp, s32}, Libcall);
|
|
|
|
|
setAction({BinOp, s64}, Libcall);
|
|
|
|
|
}
|
2016-08-30 03:07:16 +08:00
|
|
|
|
2017-03-04 07:05:47 +08:00
|
|
|
for (auto Ty : {s32, s64, p0}) {
|
2017-02-07 05:56:47 +08:00
|
|
|
setAction({G_INSERT, Ty}, Legal);
|
|
|
|
|
setAction({G_INSERT, 1, Ty}, Legal);
|
|
|
|
|
}
|
[GlobalISel] Enable legalizing non-power-of-2 sized types.
This changes the interface of how targets describe how to legalize, see
the below description.
1. Interface for targets to describe how to legalize.
In GlobalISel, the API in the LegalizerInfo class is the main interface
for targets to specify which types are legal for which operations, and
what to do to turn illegal type/operation combinations into legal ones.
For each operation the type sizes that can be legalized without having
to change the size of the type are specified with a call to setAction.
This isn't different to how GlobalISel worked before. For example, for a
target that supports 32 and 64 bit adds natively:
for (auto Ty : {s32, s64})
setAction({G_ADD, 0, s32}, Legal);
or for a target that needs a library call for a 32 bit division:
setAction({G_SDIV, s32}, Libcall);
The main conceptual change to the LegalizerInfo API, is in specifying
how to legalize the type sizes for which a change of size is needed. For
example, in the above example, how to specify how all types from i1 to
i8388607 (apart from s32 and s64 which are legal) need to be legalized
and expressed in terms of operations on the available legal sizes
(again, i32 and i64 in this case). Before, the implementation only
allowed specifying power-of-2-sized types (e.g. setAction({G_ADD, 0,
s128}, NarrowScalar). A worse limitation was that if you'd wanted to
specify how to legalize all the sized types as allowed by the LLVM-IR
LangRef, i1 to i8388607, you'd have to call setAction 8388607-3 times
and probably would need a lot of memory to store all of these
specifications.
Instead, the legalization actions that need to change the size of the
type are specified now using a "SizeChangeStrategy". For example:
setLegalizeScalarToDifferentSizeStrategy(
G_ADD, 0, widenToLargerAndNarrowToLargest);
This example indicates that for type sizes for which there is a larger
size that can be legalized towards, do it by Widening the size.
For example, G_ADD on s17 will be legalized by first doing WidenScalar
to make it s32, after which it's legal.
The "NarrowToLargest" indicates what to do if there is no larger size
that can be legalized towards. E.g. G_ADD on s92 will be legalized by
doing NarrowScalar to s64.
Another example, taken from the ARM backend is:
for (unsigned Op : {G_SDIV, G_UDIV}) {
setLegalizeScalarToDifferentSizeStrategy(Op, 0,
widenToLargerTypesUnsupportedOtherwise);
if (ST.hasDivideInARMMode())
setAction({Op, s32}, Legal);
else
setAction({Op, s32}, Libcall);
}
For this example, G_SDIV on s8, on a target without a divide
instruction, would be legalized by first doing action (WidenScalar,
s32), followed by (Libcall, s32).
The same principle is also followed for when the number of vector lanes
on vector data types need to be changed, e.g.:
setAction({G_ADD, LLT::vector(8, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(16, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(8, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(2, 32)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 32)}, LegalizerInfo::Legal);
setLegalizeVectorElementToDifferentSizeStrategy(
G_ADD, 0, widenToLargerTypesUnsupportedOtherwise);
As currently implemented here, vector types are legalized by first
making the vector element size legal, followed by then making the number
of lanes legal. The strategy to follow in the first step is set by a
call to setLegalizeVectorElementToDifferentSizeStrategy, see example
above. The strategy followed in the second step
"moreToWiderTypesAndLessToWidest" (see code for its definition),
indicating that vectors are widened to more elements so they map to
natively supported vector widths, or when there isn't a legal wider
vector, split the vector to map it to the widest vector supported.
Therefore, for the above specification, some example legalizations are:
* getAction({G_ADD, LLT::vector(3, 3)})
returns {WidenScalar, LLT::vector(3, 8)}
* getAction({G_ADD, LLT::vector(3, 8)})
then returns {MoreElements, LLT::vector(8, 8)}
* getAction({G_ADD, LLT::vector(20, 8)})
returns {FewerElements, LLT::vector(16, 8)}
2. Key implementation aspects.
How to legalize a specific (operation, type index, size) tuple is
represented by mapping intervals of integers representing a range of
size types to an action to take, e.g.:
setScalarAction({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[
});
Please note that most of the code to do the actual lowering of
non-power-of-2 sized types is currently 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 quite a bit 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 meant to be used.
This drops the need for LLT::{half,double}...Size().
Differential Revision: https://reviews.llvm.org/D30529
llvm-svn: 317560
2017-11-07 18:34:34 +08:00
|
|
|
setLegalizeScalarToDifferentSizeStrategy(G_INSERT, 0,
|
|
|
|
|
widen_1_8_16_narrowToLargest);
|
2017-02-07 05:56:47 +08:00
|
|
|
for (auto Ty : {s1, s8, s16}) {
|
2017-03-04 07:05:47 +08:00
|
|
|
setAction({G_INSERT, 1, Ty}, Legal);
|
2017-02-07 05:56:47 +08:00
|
|
|
// FIXME: Can't widen the sources because that violates the constraints on
|
|
|
|
|
// G_INSERT (It seems entirely reasonable that inputs shouldn't overlap).
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-27 04:34:13 +08:00
|
|
|
for (auto Ty : {s1, s8, s16, s32, s64, p0})
|
|
|
|
|
setAction({G_EXTRACT, Ty}, Legal);
|
|
|
|
|
|
|
|
|
|
for (auto Ty : {s32, s64})
|
|
|
|
|
setAction({G_EXTRACT, 1, Ty}, Legal);
|
|
|
|
|
|
2017-01-27 09:13:30 +08:00
|
|
|
for (unsigned MemOp : {G_LOAD, G_STORE}) {
|
2016-10-11 08:21:08 +08:00
|
|
|
for (auto Ty : {s8, s16, s32, s64, p0, v2s32})
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({MemOp, Ty}, Legal);
|
2016-08-02 23:10:28 +08:00
|
|
|
|
[GlobalISel] Enable legalizing non-power-of-2 sized types.
This changes the interface of how targets describe how to legalize, see
the below description.
1. Interface for targets to describe how to legalize.
In GlobalISel, the API in the LegalizerInfo class is the main interface
for targets to specify which types are legal for which operations, and
what to do to turn illegal type/operation combinations into legal ones.
For each operation the type sizes that can be legalized without having
to change the size of the type are specified with a call to setAction.
This isn't different to how GlobalISel worked before. For example, for a
target that supports 32 and 64 bit adds natively:
for (auto Ty : {s32, s64})
setAction({G_ADD, 0, s32}, Legal);
or for a target that needs a library call for a 32 bit division:
setAction({G_SDIV, s32}, Libcall);
The main conceptual change to the LegalizerInfo API, is in specifying
how to legalize the type sizes for which a change of size is needed. For
example, in the above example, how to specify how all types from i1 to
i8388607 (apart from s32 and s64 which are legal) need to be legalized
and expressed in terms of operations on the available legal sizes
(again, i32 and i64 in this case). Before, the implementation only
allowed specifying power-of-2-sized types (e.g. setAction({G_ADD, 0,
s128}, NarrowScalar). A worse limitation was that if you'd wanted to
specify how to legalize all the sized types as allowed by the LLVM-IR
LangRef, i1 to i8388607, you'd have to call setAction 8388607-3 times
and probably would need a lot of memory to store all of these
specifications.
Instead, the legalization actions that need to change the size of the
type are specified now using a "SizeChangeStrategy". For example:
setLegalizeScalarToDifferentSizeStrategy(
G_ADD, 0, widenToLargerAndNarrowToLargest);
This example indicates that for type sizes for which there is a larger
size that can be legalized towards, do it by Widening the size.
For example, G_ADD on s17 will be legalized by first doing WidenScalar
to make it s32, after which it's legal.
The "NarrowToLargest" indicates what to do if there is no larger size
that can be legalized towards. E.g. G_ADD on s92 will be legalized by
doing NarrowScalar to s64.
Another example, taken from the ARM backend is:
for (unsigned Op : {G_SDIV, G_UDIV}) {
setLegalizeScalarToDifferentSizeStrategy(Op, 0,
widenToLargerTypesUnsupportedOtherwise);
if (ST.hasDivideInARMMode())
setAction({Op, s32}, Legal);
else
setAction({Op, s32}, Libcall);
}
For this example, G_SDIV on s8, on a target without a divide
instruction, would be legalized by first doing action (WidenScalar,
s32), followed by (Libcall, s32).
The same principle is also followed for when the number of vector lanes
on vector data types need to be changed, e.g.:
setAction({G_ADD, LLT::vector(8, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(16, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(8, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(2, 32)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 32)}, LegalizerInfo::Legal);
setLegalizeVectorElementToDifferentSizeStrategy(
G_ADD, 0, widenToLargerTypesUnsupportedOtherwise);
As currently implemented here, vector types are legalized by first
making the vector element size legal, followed by then making the number
of lanes legal. The strategy to follow in the first step is set by a
call to setLegalizeVectorElementToDifferentSizeStrategy, see example
above. The strategy followed in the second step
"moreToWiderTypesAndLessToWidest" (see code for its definition),
indicating that vectors are widened to more elements so they map to
natively supported vector widths, or when there isn't a legal wider
vector, split the vector to map it to the widest vector supported.
Therefore, for the above specification, some example legalizations are:
* getAction({G_ADD, LLT::vector(3, 3)})
returns {WidenScalar, LLT::vector(3, 8)}
* getAction({G_ADD, LLT::vector(3, 8)})
then returns {MoreElements, LLT::vector(8, 8)}
* getAction({G_ADD, LLT::vector(20, 8)})
returns {FewerElements, LLT::vector(16, 8)}
2. Key implementation aspects.
How to legalize a specific (operation, type index, size) tuple is
represented by mapping intervals of integers representing a range of
size types to an action to take, e.g.:
setScalarAction({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[
});
Please note that most of the code to do the actual lowering of
non-power-of-2 sized types is currently 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 quite a bit 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 meant to be used.
This drops the need for LLT::{half,double}...Size().
Differential Revision: https://reviews.llvm.org/D30529
llvm-svn: 317560
2017-11-07 18:34:34 +08:00
|
|
|
setLegalizeScalarToDifferentSizeStrategy(MemOp, 0,
|
|
|
|
|
widen_1_narrow_128_ToLargest);
|
2016-08-24 03:30:42 +08:00
|
|
|
|
|
|
|
|
// And everything's fine in addrspace 0.
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({MemOp, 1, p0}, Legal);
|
2016-08-24 02:20:09 +08:00
|
|
|
}
|
|
|
|
|
|
2016-08-24 05:01:20 +08:00
|
|
|
// Constants
|
2016-08-20 06:40:00 +08:00
|
|
|
for (auto Ty : {s32, s64}) {
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({TargetOpcode::G_CONSTANT, Ty}, Legal);
|
|
|
|
|
setAction({TargetOpcode::G_FCONSTANT, Ty}, Legal);
|
2016-08-20 06:40:00 +08:00
|
|
|
}
|
|
|
|
|
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({G_CONSTANT, p0}, Legal);
|
2016-08-26 01:37:35 +08:00
|
|
|
|
[GlobalISel] Enable legalizing non-power-of-2 sized types.
This changes the interface of how targets describe how to legalize, see
the below description.
1. Interface for targets to describe how to legalize.
In GlobalISel, the API in the LegalizerInfo class is the main interface
for targets to specify which types are legal for which operations, and
what to do to turn illegal type/operation combinations into legal ones.
For each operation the type sizes that can be legalized without having
to change the size of the type are specified with a call to setAction.
This isn't different to how GlobalISel worked before. For example, for a
target that supports 32 and 64 bit adds natively:
for (auto Ty : {s32, s64})
setAction({G_ADD, 0, s32}, Legal);
or for a target that needs a library call for a 32 bit division:
setAction({G_SDIV, s32}, Libcall);
The main conceptual change to the LegalizerInfo API, is in specifying
how to legalize the type sizes for which a change of size is needed. For
example, in the above example, how to specify how all types from i1 to
i8388607 (apart from s32 and s64 which are legal) need to be legalized
and expressed in terms of operations on the available legal sizes
(again, i32 and i64 in this case). Before, the implementation only
allowed specifying power-of-2-sized types (e.g. setAction({G_ADD, 0,
s128}, NarrowScalar). A worse limitation was that if you'd wanted to
specify how to legalize all the sized types as allowed by the LLVM-IR
LangRef, i1 to i8388607, you'd have to call setAction 8388607-3 times
and probably would need a lot of memory to store all of these
specifications.
Instead, the legalization actions that need to change the size of the
type are specified now using a "SizeChangeStrategy". For example:
setLegalizeScalarToDifferentSizeStrategy(
G_ADD, 0, widenToLargerAndNarrowToLargest);
This example indicates that for type sizes for which there is a larger
size that can be legalized towards, do it by Widening the size.
For example, G_ADD on s17 will be legalized by first doing WidenScalar
to make it s32, after which it's legal.
The "NarrowToLargest" indicates what to do if there is no larger size
that can be legalized towards. E.g. G_ADD on s92 will be legalized by
doing NarrowScalar to s64.
Another example, taken from the ARM backend is:
for (unsigned Op : {G_SDIV, G_UDIV}) {
setLegalizeScalarToDifferentSizeStrategy(Op, 0,
widenToLargerTypesUnsupportedOtherwise);
if (ST.hasDivideInARMMode())
setAction({Op, s32}, Legal);
else
setAction({Op, s32}, Libcall);
}
For this example, G_SDIV on s8, on a target without a divide
instruction, would be legalized by first doing action (WidenScalar,
s32), followed by (Libcall, s32).
The same principle is also followed for when the number of vector lanes
on vector data types need to be changed, e.g.:
setAction({G_ADD, LLT::vector(8, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(16, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(8, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(2, 32)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 32)}, LegalizerInfo::Legal);
setLegalizeVectorElementToDifferentSizeStrategy(
G_ADD, 0, widenToLargerTypesUnsupportedOtherwise);
As currently implemented here, vector types are legalized by first
making the vector element size legal, followed by then making the number
of lanes legal. The strategy to follow in the first step is set by a
call to setLegalizeVectorElementToDifferentSizeStrategy, see example
above. The strategy followed in the second step
"moreToWiderTypesAndLessToWidest" (see code for its definition),
indicating that vectors are widened to more elements so they map to
natively supported vector widths, or when there isn't a legal wider
vector, split the vector to map it to the widest vector supported.
Therefore, for the above specification, some example legalizations are:
* getAction({G_ADD, LLT::vector(3, 3)})
returns {WidenScalar, LLT::vector(3, 8)}
* getAction({G_ADD, LLT::vector(3, 8)})
then returns {MoreElements, LLT::vector(8, 8)}
* getAction({G_ADD, LLT::vector(20, 8)})
returns {FewerElements, LLT::vector(16, 8)}
2. Key implementation aspects.
How to legalize a specific (operation, type index, size) tuple is
represented by mapping intervals of integers representing a range of
size types to an action to take, e.g.:
setScalarAction({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[
});
Please note that most of the code to do the actual lowering of
non-power-of-2 sized types is currently 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 quite a bit 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 meant to be used.
This drops the need for LLT::{half,double}...Size().
Differential Revision: https://reviews.llvm.org/D30529
llvm-svn: 317560
2017-11-07 18:34:34 +08:00
|
|
|
setLegalizeScalarToDifferentSizeStrategy(G_CONSTANT, 0, widen_1_8_16);
|
|
|
|
|
setLegalizeScalarToDifferentSizeStrategy(G_FCONSTANT, 0, widen_16);
|
2016-08-20 06:40:00 +08:00
|
|
|
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({G_ICMP, 1, s32}, Legal);
|
|
|
|
|
setAction({G_ICMP, 1, s64}, Legal);
|
|
|
|
|
setAction({G_ICMP, 1, p0}, Legal);
|
2016-08-27 01:46:17 +08:00
|
|
|
|
[GlobalISel] Enable legalizing non-power-of-2 sized types.
This changes the interface of how targets describe how to legalize, see
the below description.
1. Interface for targets to describe how to legalize.
In GlobalISel, the API in the LegalizerInfo class is the main interface
for targets to specify which types are legal for which operations, and
what to do to turn illegal type/operation combinations into legal ones.
For each operation the type sizes that can be legalized without having
to change the size of the type are specified with a call to setAction.
This isn't different to how GlobalISel worked before. For example, for a
target that supports 32 and 64 bit adds natively:
for (auto Ty : {s32, s64})
setAction({G_ADD, 0, s32}, Legal);
or for a target that needs a library call for a 32 bit division:
setAction({G_SDIV, s32}, Libcall);
The main conceptual change to the LegalizerInfo API, is in specifying
how to legalize the type sizes for which a change of size is needed. For
example, in the above example, how to specify how all types from i1 to
i8388607 (apart from s32 and s64 which are legal) need to be legalized
and expressed in terms of operations on the available legal sizes
(again, i32 and i64 in this case). Before, the implementation only
allowed specifying power-of-2-sized types (e.g. setAction({G_ADD, 0,
s128}, NarrowScalar). A worse limitation was that if you'd wanted to
specify how to legalize all the sized types as allowed by the LLVM-IR
LangRef, i1 to i8388607, you'd have to call setAction 8388607-3 times
and probably would need a lot of memory to store all of these
specifications.
Instead, the legalization actions that need to change the size of the
type are specified now using a "SizeChangeStrategy". For example:
setLegalizeScalarToDifferentSizeStrategy(
G_ADD, 0, widenToLargerAndNarrowToLargest);
This example indicates that for type sizes for which there is a larger
size that can be legalized towards, do it by Widening the size.
For example, G_ADD on s17 will be legalized by first doing WidenScalar
to make it s32, after which it's legal.
The "NarrowToLargest" indicates what to do if there is no larger size
that can be legalized towards. E.g. G_ADD on s92 will be legalized by
doing NarrowScalar to s64.
Another example, taken from the ARM backend is:
for (unsigned Op : {G_SDIV, G_UDIV}) {
setLegalizeScalarToDifferentSizeStrategy(Op, 0,
widenToLargerTypesUnsupportedOtherwise);
if (ST.hasDivideInARMMode())
setAction({Op, s32}, Legal);
else
setAction({Op, s32}, Libcall);
}
For this example, G_SDIV on s8, on a target without a divide
instruction, would be legalized by first doing action (WidenScalar,
s32), followed by (Libcall, s32).
The same principle is also followed for when the number of vector lanes
on vector data types need to be changed, e.g.:
setAction({G_ADD, LLT::vector(8, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(16, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(8, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(2, 32)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 32)}, LegalizerInfo::Legal);
setLegalizeVectorElementToDifferentSizeStrategy(
G_ADD, 0, widenToLargerTypesUnsupportedOtherwise);
As currently implemented here, vector types are legalized by first
making the vector element size legal, followed by then making the number
of lanes legal. The strategy to follow in the first step is set by a
call to setLegalizeVectorElementToDifferentSizeStrategy, see example
above. The strategy followed in the second step
"moreToWiderTypesAndLessToWidest" (see code for its definition),
indicating that vectors are widened to more elements so they map to
natively supported vector widths, or when there isn't a legal wider
vector, split the vector to map it to the widest vector supported.
Therefore, for the above specification, some example legalizations are:
* getAction({G_ADD, LLT::vector(3, 3)})
returns {WidenScalar, LLT::vector(3, 8)}
* getAction({G_ADD, LLT::vector(3, 8)})
then returns {MoreElements, LLT::vector(8, 8)}
* getAction({G_ADD, LLT::vector(20, 8)})
returns {FewerElements, LLT::vector(16, 8)}
2. Key implementation aspects.
How to legalize a specific (operation, type index, size) tuple is
represented by mapping intervals of integers representing a range of
size types to an action to take, e.g.:
setScalarAction({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[
});
Please note that most of the code to do the actual lowering of
non-power-of-2 sized types is currently 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 quite a bit 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 meant to be used.
This drops the need for LLT::{half,double}...Size().
Differential Revision: https://reviews.llvm.org/D30529
llvm-svn: 317560
2017-11-07 18:34:34 +08:00
|
|
|
setLegalizeScalarToDifferentSizeStrategy(G_ICMP, 0, widen_1_8_16);
|
|
|
|
|
setLegalizeScalarToDifferentSizeStrategy(G_FCMP, 0, widen_1_8_16);
|
|
|
|
|
setLegalizeScalarToDifferentSizeStrategy(G_ICMP, 1, widen_1_8_16);
|
2016-08-24 05:01:26 +08:00
|
|
|
|
2017-08-01 01:00:16 +08:00
|
|
|
setAction({G_ICMP, s32}, Legal);
|
|
|
|
|
setAction({G_FCMP, s32}, Legal);
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({G_FCMP, 1, s32}, Legal);
|
|
|
|
|
setAction({G_FCMP, 1, s64}, Legal);
|
2016-08-27 01:46:19 +08:00
|
|
|
|
2016-08-26 01:37:25 +08:00
|
|
|
// Extensions
|
|
|
|
|
for (auto Ty : { s1, s8, s16, s32, s64 }) {
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({G_ZEXT, Ty}, Legal);
|
|
|
|
|
setAction({G_SEXT, Ty}, Legal);
|
|
|
|
|
setAction({G_ANYEXT, Ty}, Legal);
|
2016-08-26 01:37:25 +08:00
|
|
|
}
|
|
|
|
|
|
2017-09-13 05:04:11 +08:00
|
|
|
// FP conversions
|
|
|
|
|
for (auto Ty : { s16, s32 }) {
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({G_FPTRUNC, Ty}, Legal);
|
2017-09-13 05:04:11 +08:00
|
|
|
setAction({G_FPEXT, 1, Ty}, Legal);
|
|
|
|
|
}
|
2016-08-26 01:37:32 +08:00
|
|
|
|
2017-09-13 05:04:11 +08:00
|
|
|
for (auto Ty : { s32, s64 }) {
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({G_FPTRUNC, 1, Ty}, Legal);
|
2017-09-13 05:04:11 +08:00
|
|
|
setAction({G_FPEXT, Ty}, Legal);
|
|
|
|
|
}
|
2016-08-26 01:37:32 +08:00
|
|
|
|
2016-08-27 01:45:58 +08:00
|
|
|
// Conversions
|
2017-01-20 09:37:24 +08:00
|
|
|
for (auto Ty : { s32, s64 }) {
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({G_FPTOSI, 0, Ty}, Legal);
|
|
|
|
|
setAction({G_FPTOUI, 0, Ty}, Legal);
|
|
|
|
|
setAction({G_SITOFP, 1, Ty}, Legal);
|
|
|
|
|
setAction({G_UITOFP, 1, Ty}, Legal);
|
2016-08-27 01:45:58 +08:00
|
|
|
}
|
[GlobalISel] Enable legalizing non-power-of-2 sized types.
This changes the interface of how targets describe how to legalize, see
the below description.
1. Interface for targets to describe how to legalize.
In GlobalISel, the API in the LegalizerInfo class is the main interface
for targets to specify which types are legal for which operations, and
what to do to turn illegal type/operation combinations into legal ones.
For each operation the type sizes that can be legalized without having
to change the size of the type are specified with a call to setAction.
This isn't different to how GlobalISel worked before. For example, for a
target that supports 32 and 64 bit adds natively:
for (auto Ty : {s32, s64})
setAction({G_ADD, 0, s32}, Legal);
or for a target that needs a library call for a 32 bit division:
setAction({G_SDIV, s32}, Libcall);
The main conceptual change to the LegalizerInfo API, is in specifying
how to legalize the type sizes for which a change of size is needed. For
example, in the above example, how to specify how all types from i1 to
i8388607 (apart from s32 and s64 which are legal) need to be legalized
and expressed in terms of operations on the available legal sizes
(again, i32 and i64 in this case). Before, the implementation only
allowed specifying power-of-2-sized types (e.g. setAction({G_ADD, 0,
s128}, NarrowScalar). A worse limitation was that if you'd wanted to
specify how to legalize all the sized types as allowed by the LLVM-IR
LangRef, i1 to i8388607, you'd have to call setAction 8388607-3 times
and probably would need a lot of memory to store all of these
specifications.
Instead, the legalization actions that need to change the size of the
type are specified now using a "SizeChangeStrategy". For example:
setLegalizeScalarToDifferentSizeStrategy(
G_ADD, 0, widenToLargerAndNarrowToLargest);
This example indicates that for type sizes for which there is a larger
size that can be legalized towards, do it by Widening the size.
For example, G_ADD on s17 will be legalized by first doing WidenScalar
to make it s32, after which it's legal.
The "NarrowToLargest" indicates what to do if there is no larger size
that can be legalized towards. E.g. G_ADD on s92 will be legalized by
doing NarrowScalar to s64.
Another example, taken from the ARM backend is:
for (unsigned Op : {G_SDIV, G_UDIV}) {
setLegalizeScalarToDifferentSizeStrategy(Op, 0,
widenToLargerTypesUnsupportedOtherwise);
if (ST.hasDivideInARMMode())
setAction({Op, s32}, Legal);
else
setAction({Op, s32}, Libcall);
}
For this example, G_SDIV on s8, on a target without a divide
instruction, would be legalized by first doing action (WidenScalar,
s32), followed by (Libcall, s32).
The same principle is also followed for when the number of vector lanes
on vector data types need to be changed, e.g.:
setAction({G_ADD, LLT::vector(8, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(16, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(8, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(2, 32)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 32)}, LegalizerInfo::Legal);
setLegalizeVectorElementToDifferentSizeStrategy(
G_ADD, 0, widenToLargerTypesUnsupportedOtherwise);
As currently implemented here, vector types are legalized by first
making the vector element size legal, followed by then making the number
of lanes legal. The strategy to follow in the first step is set by a
call to setLegalizeVectorElementToDifferentSizeStrategy, see example
above. The strategy followed in the second step
"moreToWiderTypesAndLessToWidest" (see code for its definition),
indicating that vectors are widened to more elements so they map to
natively supported vector widths, or when there isn't a legal wider
vector, split the vector to map it to the widest vector supported.
Therefore, for the above specification, some example legalizations are:
* getAction({G_ADD, LLT::vector(3, 3)})
returns {WidenScalar, LLT::vector(3, 8)}
* getAction({G_ADD, LLT::vector(3, 8)})
then returns {MoreElements, LLT::vector(8, 8)}
* getAction({G_ADD, LLT::vector(20, 8)})
returns {FewerElements, LLT::vector(16, 8)}
2. Key implementation aspects.
How to legalize a specific (operation, type index, size) tuple is
represented by mapping intervals of integers representing a range of
size types to an action to take, e.g.:
setScalarAction({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[
});
Please note that most of the code to do the actual lowering of
non-power-of-2 sized types is currently 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 quite a bit 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 meant to be used.
This drops the need for LLT::{half,double}...Size().
Differential Revision: https://reviews.llvm.org/D30529
llvm-svn: 317560
2017-11-07 18:34:34 +08:00
|
|
|
setLegalizeScalarToDifferentSizeStrategy(G_FPTOSI, 0, widen_1_8_16);
|
|
|
|
|
setLegalizeScalarToDifferentSizeStrategy(G_FPTOUI, 0, widen_1_8_16);
|
|
|
|
|
setLegalizeScalarToDifferentSizeStrategy(G_SITOFP, 1, widen_1_8_16);
|
|
|
|
|
setLegalizeScalarToDifferentSizeStrategy(G_UITOFP, 1, widen_1_8_16);
|
2016-08-27 01:45:58 +08:00
|
|
|
|
|
|
|
|
for (auto Ty : { s32, s64 }) {
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({G_FPTOSI, 1, Ty}, Legal);
|
|
|
|
|
setAction({G_FPTOUI, 1, Ty}, Legal);
|
|
|
|
|
setAction({G_SITOFP, 0, Ty}, Legal);
|
|
|
|
|
setAction({G_UITOFP, 0, Ty}, Legal);
|
2016-08-27 01:45:58 +08:00
|
|
|
}
|
2016-08-26 01:37:32 +08:00
|
|
|
|
2016-08-24 05:01:20 +08:00
|
|
|
// Control-flow
|
2016-10-13 06:48:36 +08:00
|
|
|
for (auto Ty : {s1, s8, s16, s32})
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({G_BRCOND, Ty}, Legal);
|
2017-01-30 17:13:18 +08:00
|
|
|
setAction({G_BRINDIRECT, p0}, Legal);
|
2016-08-05 04:54:13 +08:00
|
|
|
|
2016-08-27 01:46:03 +08:00
|
|
|
// Select
|
[GlobalISel] Enable legalizing non-power-of-2 sized types.
This changes the interface of how targets describe how to legalize, see
the below description.
1. Interface for targets to describe how to legalize.
In GlobalISel, the API in the LegalizerInfo class is the main interface
for targets to specify which types are legal for which operations, and
what to do to turn illegal type/operation combinations into legal ones.
For each operation the type sizes that can be legalized without having
to change the size of the type are specified with a call to setAction.
This isn't different to how GlobalISel worked before. For example, for a
target that supports 32 and 64 bit adds natively:
for (auto Ty : {s32, s64})
setAction({G_ADD, 0, s32}, Legal);
or for a target that needs a library call for a 32 bit division:
setAction({G_SDIV, s32}, Libcall);
The main conceptual change to the LegalizerInfo API, is in specifying
how to legalize the type sizes for which a change of size is needed. For
example, in the above example, how to specify how all types from i1 to
i8388607 (apart from s32 and s64 which are legal) need to be legalized
and expressed in terms of operations on the available legal sizes
(again, i32 and i64 in this case). Before, the implementation only
allowed specifying power-of-2-sized types (e.g. setAction({G_ADD, 0,
s128}, NarrowScalar). A worse limitation was that if you'd wanted to
specify how to legalize all the sized types as allowed by the LLVM-IR
LangRef, i1 to i8388607, you'd have to call setAction 8388607-3 times
and probably would need a lot of memory to store all of these
specifications.
Instead, the legalization actions that need to change the size of the
type are specified now using a "SizeChangeStrategy". For example:
setLegalizeScalarToDifferentSizeStrategy(
G_ADD, 0, widenToLargerAndNarrowToLargest);
This example indicates that for type sizes for which there is a larger
size that can be legalized towards, do it by Widening the size.
For example, G_ADD on s17 will be legalized by first doing WidenScalar
to make it s32, after which it's legal.
The "NarrowToLargest" indicates what to do if there is no larger size
that can be legalized towards. E.g. G_ADD on s92 will be legalized by
doing NarrowScalar to s64.
Another example, taken from the ARM backend is:
for (unsigned Op : {G_SDIV, G_UDIV}) {
setLegalizeScalarToDifferentSizeStrategy(Op, 0,
widenToLargerTypesUnsupportedOtherwise);
if (ST.hasDivideInARMMode())
setAction({Op, s32}, Legal);
else
setAction({Op, s32}, Libcall);
}
For this example, G_SDIV on s8, on a target without a divide
instruction, would be legalized by first doing action (WidenScalar,
s32), followed by (Libcall, s32).
The same principle is also followed for when the number of vector lanes
on vector data types need to be changed, e.g.:
setAction({G_ADD, LLT::vector(8, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(16, 8)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(8, 16)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(2, 32)}, LegalizerInfo::Legal);
setAction({G_ADD, LLT::vector(4, 32)}, LegalizerInfo::Legal);
setLegalizeVectorElementToDifferentSizeStrategy(
G_ADD, 0, widenToLargerTypesUnsupportedOtherwise);
As currently implemented here, vector types are legalized by first
making the vector element size legal, followed by then making the number
of lanes legal. The strategy to follow in the first step is set by a
call to setLegalizeVectorElementToDifferentSizeStrategy, see example
above. The strategy followed in the second step
"moreToWiderTypesAndLessToWidest" (see code for its definition),
indicating that vectors are widened to more elements so they map to
natively supported vector widths, or when there isn't a legal wider
vector, split the vector to map it to the widest vector supported.
Therefore, for the above specification, some example legalizations are:
* getAction({G_ADD, LLT::vector(3, 3)})
returns {WidenScalar, LLT::vector(3, 8)}
* getAction({G_ADD, LLT::vector(3, 8)})
then returns {MoreElements, LLT::vector(8, 8)}
* getAction({G_ADD, LLT::vector(20, 8)})
returns {FewerElements, LLT::vector(16, 8)}
2. Key implementation aspects.
How to legalize a specific (operation, type index, size) tuple is
represented by mapping intervals of integers representing a range of
size types to an action to take, e.g.:
setScalarAction({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[
});
Please note that most of the code to do the actual lowering of
non-power-of-2 sized types is currently 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 quite a bit 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 meant to be used.
This drops the need for LLT::{half,double}...Size().
Differential Revision: https://reviews.llvm.org/D30529
llvm-svn: 317560
2017-11-07 18:34:34 +08:00
|
|
|
setLegalizeScalarToDifferentSizeStrategy(G_SELECT, 0, widen_1_8_16);
|
2017-02-07 07:41:27 +08:00
|
|
|
|
|
|
|
|
for (auto Ty : {s32, s64, p0})
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({G_SELECT, Ty}, Legal);
|
2016-08-27 01:46:03 +08:00
|
|
|
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({G_SELECT, 1, s1}, Legal);
|
2016-08-27 01:46:03 +08:00
|
|
|
|
2016-08-24 05:01:20 +08:00
|
|
|
// Pointer-handling
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({G_FRAME_INDEX, p0}, Legal);
|
|
|
|
|
setAction({G_GLOBAL_VALUE, p0}, Legal);
|
2016-08-02 23:10:28 +08:00
|
|
|
|
2016-11-01 02:31:09 +08:00
|
|
|
for (auto Ty : {s1, s8, s16, s32, s64})
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({G_PTRTOINT, 0, Ty}, Legal);
|
2016-11-01 02:31:09 +08:00
|
|
|
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({G_PTRTOINT, 1, p0}, Legal);
|
2016-08-16 22:02:42 +08:00
|
|
|
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({G_INTTOPTR, 0, p0}, Legal);
|
|
|
|
|
setAction({G_INTTOPTR, 1, s64}, Legal);
|
2016-08-24 03:30:38 +08:00
|
|
|
|
2016-10-12 11:57:43 +08:00
|
|
|
// Casts for 32 and 64-bit width type are just copies.
|
2017-10-17 06:28:27 +08:00
|
|
|
// Same for 128-bit width type, except they are on the FPR bank.
|
|
|
|
|
for (auto Ty : {s1, s8, s16, s32, s64, s128}) {
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({G_BITCAST, 0, Ty}, Legal);
|
|
|
|
|
setAction({G_BITCAST, 1, Ty}, Legal);
|
2016-10-12 06:29:23 +08:00
|
|
|
}
|
|
|
|
|
|
2016-10-13 08:12:01 +08:00
|
|
|
// For the sake of copying bits around, the type does not really
|
|
|
|
|
// matter as long as it fits a register.
|
2016-10-12 06:29:23 +08:00
|
|
|
for (int EltSize = 8; EltSize <= 64; EltSize *= 2) {
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({G_BITCAST, 0, LLT::vector(128/EltSize, EltSize)}, Legal);
|
|
|
|
|
setAction({G_BITCAST, 1, LLT::vector(128/EltSize, EltSize)}, Legal);
|
2016-10-13 08:12:01 +08:00
|
|
|
if (EltSize >= 64)
|
2016-10-12 06:29:23 +08:00
|
|
|
continue;
|
|
|
|
|
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({G_BITCAST, 0, LLT::vector(64/EltSize, EltSize)}, Legal);
|
|
|
|
|
setAction({G_BITCAST, 1, LLT::vector(64/EltSize, EltSize)}, Legal);
|
2016-10-13 08:12:01 +08:00
|
|
|
if (EltSize >= 32)
|
|
|
|
|
continue;
|
|
|
|
|
|
2017-01-27 09:13:25 +08:00
|
|
|
setAction({G_BITCAST, 0, LLT::vector(32/EltSize, EltSize)}, Legal);
|
|
|
|
|
setAction({G_BITCAST, 1, LLT::vector(32/EltSize, EltSize)}, Legal);
|
2016-10-12 06:29:23 +08:00
|
|
|
}
|
|
|
|
|
|
2017-02-09 01:57:27 +08:00
|
|
|
setAction({G_VASTART, p0}, Legal);
|
|
|
|
|
|
2017-02-16 07:22:50 +08:00
|
|
|
// va_list must be a pointer, but most sized types are pretty easy to handle
|
|
|
|
|
// as the destination.
|
|
|
|
|
setAction({G_VAARG, 1, p0}, Legal);
|
|
|
|
|
|
|
|
|
|
for (auto Ty : {s8, s16, s32, s64, p0})
|
|
|
|
|
setAction({G_VAARG, Ty}, Custom);
|
|
|
|
|
|
2017-11-29 04:21:15 +08:00
|
|
|
if (ST.hasLSE()) {
|
2017-12-01 04:11:42 +08:00
|
|
|
for (auto Ty : {s8, s16, s32, s64}) {
|
|
|
|
|
setAction({G_ATOMIC_CMPXCHG_WITH_SUCCESS, Ty}, Lower);
|
2017-11-29 04:21:15 +08:00
|
|
|
setAction({G_ATOMIC_CMPXCHG, Ty}, Legal);
|
2017-12-01 04:11:42 +08:00
|
|
|
}
|
2017-11-29 04:21:15 +08:00
|
|
|
setAction({G_ATOMIC_CMPXCHG, 1, p0}, Legal);
|
|
|
|
|
|
2017-11-29 06:32:43 +08:00
|
|
|
for (unsigned Op :
|
2017-11-29 04:21:15 +08:00
|
|
|
{G_ATOMICRMW_XCHG, G_ATOMICRMW_ADD, G_ATOMICRMW_SUB, G_ATOMICRMW_AND,
|
|
|
|
|
G_ATOMICRMW_OR, G_ATOMICRMW_XOR, G_ATOMICRMW_MIN, G_ATOMICRMW_MAX,
|
|
|
|
|
G_ATOMICRMW_UMIN, G_ATOMICRMW_UMAX}) {
|
|
|
|
|
for (auto Ty : {s8, s16, s32, s64}) {
|
|
|
|
|
setAction({Op, Ty}, Legal);
|
|
|
|
|
}
|
|
|
|
|
setAction({Op, 1, p0}, Legal);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-01 16:19:10 +08:00
|
|
|
// Merge/Unmerge
|
|
|
|
|
for (unsigned Op : {G_MERGE_VALUES, G_UNMERGE_VALUES})
|
|
|
|
|
for (int Sz : {8, 16, 32, 64, 128, 192, 256, 384, 512}) {
|
|
|
|
|
LLT ScalarTy = LLT::scalar(Sz);
|
|
|
|
|
setAction({Op, ScalarTy}, Legal);
|
|
|
|
|
setAction({Op, 1, ScalarTy}, Legal);
|
|
|
|
|
if (Sz < 32)
|
|
|
|
|
continue;
|
|
|
|
|
for (int EltSize = 8; EltSize <= 64; EltSize *= 2) {
|
|
|
|
|
if (EltSize >= Sz)
|
|
|
|
|
continue;
|
|
|
|
|
LLT VecTy = LLT::vector(Sz / EltSize, EltSize);
|
|
|
|
|
setAction({Op, VecTy}, Legal);
|
|
|
|
|
setAction({Op, 1, VecTy}, Legal);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-23 04:03:43 +08:00
|
|
|
computeTables();
|
|
|
|
|
}
|
2017-02-16 07:22:50 +08:00
|
|
|
|
|
|
|
|
bool AArch64LegalizerInfo::legalizeCustom(MachineInstr &MI,
|
|
|
|
|
MachineRegisterInfo &MRI,
|
|
|
|
|
MachineIRBuilder &MIRBuilder) const {
|
|
|
|
|
switch (MI.getOpcode()) {
|
|
|
|
|
default:
|
|
|
|
|
// No idea what to do.
|
|
|
|
|
return false;
|
|
|
|
|
case TargetOpcode::G_VAARG:
|
|
|
|
|
return legalizeVaArg(MI, MRI, MIRBuilder);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
llvm_unreachable("expected switch to return");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool AArch64LegalizerInfo::legalizeVaArg(MachineInstr &MI,
|
|
|
|
|
MachineRegisterInfo &MRI,
|
|
|
|
|
MachineIRBuilder &MIRBuilder) const {
|
|
|
|
|
MIRBuilder.setInstr(MI);
|
|
|
|
|
MachineFunction &MF = MIRBuilder.getMF();
|
|
|
|
|
unsigned Align = MI.getOperand(2).getImm();
|
|
|
|
|
unsigned Dst = MI.getOperand(0).getReg();
|
|
|
|
|
unsigned ListPtr = MI.getOperand(1).getReg();
|
|
|
|
|
|
|
|
|
|
LLT PtrTy = MRI.getType(ListPtr);
|
|
|
|
|
LLT IntPtrTy = LLT::scalar(PtrTy.getSizeInBits());
|
|
|
|
|
|
|
|
|
|
const unsigned PtrSize = PtrTy.getSizeInBits() / 8;
|
|
|
|
|
unsigned List = MRI.createGenericVirtualRegister(PtrTy);
|
|
|
|
|
MIRBuilder.buildLoad(
|
|
|
|
|
List, ListPtr,
|
|
|
|
|
*MF.getMachineMemOperand(MachinePointerInfo(), MachineMemOperand::MOLoad,
|
|
|
|
|
PtrSize, /* Align = */ PtrSize));
|
|
|
|
|
|
|
|
|
|
unsigned DstPtr;
|
|
|
|
|
if (Align > PtrSize) {
|
|
|
|
|
// Realign the list to the actual required alignment.
|
2017-07-07 03:40:07 +08:00
|
|
|
auto AlignMinus1 = MIRBuilder.buildConstant(IntPtrTy, Align - 1);
|
2017-02-16 07:22:50 +08:00
|
|
|
|
|
|
|
|
unsigned ListTmp = MRI.createGenericVirtualRegister(PtrTy);
|
2017-07-07 03:40:07 +08:00
|
|
|
MIRBuilder.buildGEP(ListTmp, List, AlignMinus1->getOperand(0).getReg());
|
2017-02-16 07:22:50 +08:00
|
|
|
|
|
|
|
|
DstPtr = MRI.createGenericVirtualRegister(PtrTy);
|
|
|
|
|
MIRBuilder.buildPtrMask(DstPtr, ListTmp, Log2_64(Align));
|
|
|
|
|
} else
|
|
|
|
|
DstPtr = List;
|
|
|
|
|
|
|
|
|
|
uint64_t ValSize = MRI.getType(Dst).getSizeInBits() / 8;
|
|
|
|
|
MIRBuilder.buildLoad(
|
|
|
|
|
Dst, DstPtr,
|
|
|
|
|
*MF.getMachineMemOperand(MachinePointerInfo(), MachineMemOperand::MOLoad,
|
|
|
|
|
ValSize, std::max(Align, PtrSize)));
|
|
|
|
|
|
|
|
|
|
unsigned SizeReg = MRI.createGenericVirtualRegister(IntPtrTy);
|
|
|
|
|
MIRBuilder.buildConstant(SizeReg, alignTo(ValSize, PtrSize));
|
|
|
|
|
|
|
|
|
|
unsigned NewList = MRI.createGenericVirtualRegister(PtrTy);
|
|
|
|
|
MIRBuilder.buildGEP(NewList, DstPtr, SizeReg);
|
|
|
|
|
|
|
|
|
|
MIRBuilder.buildStore(
|
|
|
|
|
NewList, ListPtr,
|
|
|
|
|
*MF.getMachineMemOperand(MachinePointerInfo(), MachineMemOperand::MOStore,
|
|
|
|
|
PtrSize, /* Align = */ PtrSize));
|
|
|
|
|
|
|
|
|
|
MI.eraseFromParent();
|
|
|
|
|
return true;
|
|
|
|
|
}
|