forked from OSchip/llvm-project
af9814a1fc
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
|
||
|---|---|---|
| .. | ||
| Unix | ||
| Windows | ||
| AMDGPUMetadata.cpp | ||
| APFloat.cpp | ||
| APInt.cpp | ||
| APSInt.cpp | ||
| ARMAttributeParser.cpp | ||
| ARMBuildAttrs.cpp | ||
| ARMWinEH.cpp | ||
| Allocator.cpp | ||
| Atomic.cpp | ||
| BinaryStreamError.cpp | ||
| BinaryStreamReader.cpp | ||
| BinaryStreamRef.cpp | ||
| BinaryStreamWriter.cpp | ||
| BlockFrequency.cpp | ||
| BranchProbability.cpp | ||
| CMakeLists.txt | ||
| COM.cpp | ||
| COPYRIGHT.regex | ||
| CachePruning.cpp | ||
| Chrono.cpp | ||
| CommandLine.cpp | ||
| Compression.cpp | ||
| ConvertUTF.cpp | ||
| ConvertUTFWrapper.cpp | ||
| CrashRecoveryContext.cpp | ||
| DAGDeltaAlgorithm.cpp | ||
| DataExtractor.cpp | ||
| Debug.cpp | ||
| DebugCounter.cpp | ||
| DeltaAlgorithm.cpp | ||
| DynamicLibrary.cpp | ||
| Errno.cpp | ||
| Error.cpp | ||
| ErrorHandling.cpp | ||
| FileOutputBuffer.cpp | ||
| FileUtilities.cpp | ||
| FoldingSet.cpp | ||
| FormatVariadic.cpp | ||
| FormattedStream.cpp | ||
| GlobPattern.cpp | ||
| GraphWriter.cpp | ||
| Hashing.cpp | ||
| Host.cpp | ||
| IntEqClasses.cpp | ||
| IntervalMap.cpp | ||
| JamCRC.cpp | ||
| KnownBits.cpp | ||
| LEB128.cpp | ||
| LLVMBuild.txt | ||
| LineIterator.cpp | ||
| Locale.cpp | ||
| LockFileManager.cpp | ||
| LowLevelType.cpp | ||
| MD5.cpp | ||
| ManagedStatic.cpp | ||
| MathExtras.cpp | ||
| Memory.cpp | ||
| MemoryBuffer.cpp | ||
| Mutex.cpp | ||
| NativeFormatting.cpp | ||
| Options.cpp | ||
| Parallel.cpp | ||
| Path.cpp | ||
| PluginLoader.cpp | ||
| PrettyStackTrace.cpp | ||
| Process.cpp | ||
| Program.cpp | ||
| README.txt.system | ||
| RWMutex.cpp | ||
| RandomNumberGenerator.cpp | ||
| Regex.cpp | ||
| SHA1.cpp | ||
| ScaledNumber.cpp | ||
| ScopedPrinter.cpp | ||
| Signals.cpp | ||
| SmallPtrSet.cpp | ||
| SmallVector.cpp | ||
| SourceMgr.cpp | ||
| SpecialCaseList.cpp | ||
| Statistic.cpp | ||
| StringExtras.cpp | ||
| StringMap.cpp | ||
| StringPool.cpp | ||
| StringRef.cpp | ||
| StringSaver.cpp | ||
| SystemUtils.cpp | ||
| TarWriter.cpp | ||
| TargetParser.cpp | ||
| TargetRegistry.cpp | ||
| ThreadLocal.cpp | ||
| ThreadPool.cpp | ||
| Threading.cpp | ||
| Timer.cpp | ||
| ToolOutputFile.cpp | ||
| TrigramIndex.cpp | ||
| Triple.cpp | ||
| Twine.cpp | ||
| Unicode.cpp | ||
| Valgrind.cpp | ||
| Watchdog.cpp | ||
| YAMLParser.cpp | ||
| YAMLTraits.cpp | ||
| circular_raw_ostream.cpp | ||
| raw_os_ostream.cpp | ||
| raw_ostream.cpp | ||
| regcomp.c | ||
| regengine.inc | ||
| regerror.c | ||
| regex2.h | ||
| regex_impl.h | ||
| regexec.c | ||
| regfree.c | ||
| regstrlcpy.c | ||
| regutils.h | ||
| xxhash.cpp | ||
README.txt.system
Design Of lib/System
====================
The software in this directory is designed to completely shield LLVM from any
and all operating system specific functionality. It is not intended to be a
complete operating system wrapper (such as ACE), but only to provide the
functionality necessary to support LLVM.
The software located here, of necessity, has very specific and stringent design
rules. Violation of these rules means that cracks in the shield could form and
the primary goal of the library is defeated. By consistently using this library,
LLVM becomes more easily ported to new platforms since the only thing requiring
porting is this library.
Complete documentation for the library can be found in the file:
llvm/docs/SystemLibrary.html
or at this URL:
http://llvm.org/docs/SystemLibrary.html
While we recommend that you read the more detailed documentation, for the
impatient, here's a high level summary of the library's requirements.
1. No system header files are to be exposed through the interface.
2. Std C++ and Std C header files are okay to be exposed through the interface.
3. No exposed system-specific functions.
4. No exposed system-specific data.
5. Data in lib/System classes must use only simple C++ intrinsic types.
6. Errors are handled by returning "true" and setting an optional std::string
7. Library must not throw any exceptions, period.
8. Interface functions must not have throw() specifications.
9. No duplicate function impementations are permitted within an operating
system class.
To accomplish these requirements, the library has numerous design criteria that
must be satisfied. Here's a high level summary of the library's design criteria:
1. No unused functionality (only what LLVM needs)
2. High-Level Interfaces
3. Use Opaque Classes
4. Common Implementations
5. Multiple Implementations
6. Minimize Memory Allocation
7. No Virtual Methods