2019-07-16 20:28:56 +08:00
|
|
|
//===- jit-runner.cpp - MLIR CPU Execution Driver Library -----------------===//
|
2019-05-14 01:59:04 +08:00
|
|
|
//
|
2020-01-26 11:58:30 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
2019-12-24 01:35:36 +08:00
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2019-05-14 01:59:04 +08:00
|
|
|
//
|
2019-12-24 01:35:36 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2019-05-14 01:59:04 +08:00
|
|
|
//
|
2019-07-16 20:28:56 +08:00
|
|
|
// This is a library that provides a shared implementation for command line
|
|
|
|
// utilities that execute an MLIR file on the CPU by translating MLIR to LLVM
|
|
|
|
// IR before JIT-compiling and executing the latter.
|
2019-05-14 01:59:04 +08:00
|
|
|
//
|
2019-07-16 20:28:56 +08:00
|
|
|
// The translation can be customized by providing an MLIR to MLIR
|
|
|
|
// transformation.
|
2019-05-14 01:59:04 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2020-05-14 03:01:40 +08:00
|
|
|
#include "mlir/ExecutionEngine/JitRunner.h"
|
2019-07-16 20:28:56 +08:00
|
|
|
|
2019-08-20 02:00:47 +08:00
|
|
|
#include "mlir/Dialect/LLVMIR/LLVMDialect.h"
|
2019-05-14 01:59:04 +08:00
|
|
|
#include "mlir/ExecutionEngine/ExecutionEngine.h"
|
|
|
|
#include "mlir/ExecutionEngine/OptUtils.h"
|
2020-12-04 09:22:29 +08:00
|
|
|
#include "mlir/IR/BuiltinTypes.h"
|
2019-05-14 01:59:04 +08:00
|
|
|
#include "mlir/IR/MLIRContext.h"
|
2020-10-24 04:19:35 +08:00
|
|
|
#include "mlir/InitAllDialects.h"
|
2019-05-14 01:59:04 +08:00
|
|
|
#include "mlir/Parser.h"
|
|
|
|
#include "mlir/Support/FileUtilities.h"
|
|
|
|
|
2019-07-04 22:49:52 +08:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2019-08-09 07:02:50 +08:00
|
|
|
#include "llvm/ExecutionEngine/Orc/JITTargetMachineBuilder.h"
|
2019-05-14 01:59:04 +08:00
|
|
|
#include "llvm/IR/IRBuilder.h"
|
|
|
|
#include "llvm/IR/LLVMContext.h"
|
|
|
|
#include "llvm/IR/LegacyPassNameParser.h"
|
|
|
|
#include "llvm/Support/CommandLine.h"
|
|
|
|
#include "llvm/Support/FileUtilities.h"
|
|
|
|
#include "llvm/Support/SourceMgr.h"
|
|
|
|
#include "llvm/Support/StringSaver.h"
|
|
|
|
#include "llvm/Support/ToolOutputFile.h"
|
2019-11-23 08:04:44 +08:00
|
|
|
#include <cstdint>
|
2019-05-14 01:59:04 +08:00
|
|
|
#include <numeric>
|
|
|
|
|
|
|
|
using namespace mlir;
|
|
|
|
using llvm::Error;
|
|
|
|
|
2020-04-09 09:33:24 +08:00
|
|
|
namespace {
|
|
|
|
/// This options struct prevents the need for global static initializers, and
|
|
|
|
/// is only initialized if the JITRunner is invoked.
|
|
|
|
struct Options {
|
|
|
|
llvm::cl::opt<std::string> inputFilename{llvm::cl::Positional,
|
|
|
|
llvm::cl::desc("<input file>"),
|
|
|
|
llvm::cl::init("-")};
|
|
|
|
llvm::cl::opt<std::string> mainFuncName{
|
|
|
|
"e", llvm::cl::desc("The function to be called"),
|
|
|
|
llvm::cl::value_desc("<function name>"), llvm::cl::init("main")};
|
|
|
|
llvm::cl::opt<std::string> mainFuncType{
|
|
|
|
"entry-point-result",
|
|
|
|
llvm::cl::desc("Textual description of the function type to be called"),
|
2019-11-23 08:04:44 +08:00
|
|
|
llvm::cl::value_desc("f32 | i32 | i64 | void"), llvm::cl::init("f32")};
|
2020-04-09 09:33:24 +08:00
|
|
|
|
|
|
|
llvm::cl::OptionCategory optFlags{"opt-like flags"};
|
|
|
|
|
|
|
|
// CLI list of pass information
|
|
|
|
llvm::cl::list<const llvm::PassInfo *, bool, llvm::PassNameParser> llvmPasses{
|
|
|
|
llvm::cl::desc("LLVM optimizing passes to run"), llvm::cl::cat(optFlags)};
|
|
|
|
|
|
|
|
// CLI variables for -On options.
|
|
|
|
llvm::cl::opt<bool> optO0{"O0",
|
|
|
|
llvm::cl::desc("Run opt passes and codegen at O0"),
|
|
|
|
llvm::cl::cat(optFlags)};
|
|
|
|
llvm::cl::opt<bool> optO1{"O1",
|
|
|
|
llvm::cl::desc("Run opt passes and codegen at O1"),
|
|
|
|
llvm::cl::cat(optFlags)};
|
|
|
|
llvm::cl::opt<bool> optO2{"O2",
|
|
|
|
llvm::cl::desc("Run opt passes and codegen at O2"),
|
|
|
|
llvm::cl::cat(optFlags)};
|
|
|
|
llvm::cl::opt<bool> optO3{"O3",
|
|
|
|
llvm::cl::desc("Run opt passes and codegen at O3"),
|
|
|
|
llvm::cl::cat(optFlags)};
|
|
|
|
|
|
|
|
llvm::cl::OptionCategory clOptionsCategory{"linking options"};
|
|
|
|
llvm::cl::list<std::string> clSharedLibs{
|
|
|
|
"shared-libs", llvm::cl::desc("Libraries to link dynamically"),
|
|
|
|
llvm::cl::ZeroOrMore, llvm::cl::MiscFlags::CommaSeparated,
|
|
|
|
llvm::cl::cat(clOptionsCategory)};
|
|
|
|
|
|
|
|
/// CLI variables for debugging.
|
|
|
|
llvm::cl::opt<bool> dumpObjectFile{
|
|
|
|
"dump-object-file",
|
|
|
|
llvm::cl::desc("Dump JITted-compiled object to file specified with "
|
|
|
|
"-object-filename (<input file>.o by default).")};
|
|
|
|
|
|
|
|
llvm::cl::opt<std::string> objectFilename{
|
|
|
|
"object-filename",
|
|
|
|
llvm::cl::desc("Dump JITted-compiled object to file <input file>.o")};
|
|
|
|
};
|
2020-10-28 05:12:47 +08:00
|
|
|
|
|
|
|
struct CompileAndExecuteConfig {
|
|
|
|
/// LLVM module transformer that is passed to ExecutionEngine.
|
|
|
|
llvm::function_ref<llvm::Error(llvm::Module *)> transformer;
|
|
|
|
|
|
|
|
/// A custom function that is passed to ExecutionEngine. It processes MLIR
|
|
|
|
/// module and creates LLVM IR module.
|
|
|
|
llvm::function_ref<std::unique_ptr<llvm::Module>(ModuleOp,
|
|
|
|
llvm::LLVMContext &)>
|
|
|
|
llvmModuleBuilder;
|
|
|
|
|
|
|
|
/// A custom function that is passed to ExecutinEngine to register symbols at
|
|
|
|
/// runtime.
|
|
|
|
llvm::function_ref<llvm::orc::SymbolMap(llvm::orc::MangleAndInterner)>
|
|
|
|
runtimeSymbolMap;
|
|
|
|
};
|
|
|
|
|
2020-04-09 09:33:24 +08:00
|
|
|
} // end anonymous namespace
|
2019-08-31 04:01:34 +08:00
|
|
|
|
2019-07-03 01:49:17 +08:00
|
|
|
static OwningModuleRef parseMLIRInput(StringRef inputFilename,
|
|
|
|
MLIRContext *context) {
|
2019-05-14 01:59:04 +08:00
|
|
|
// Set up the input file.
|
|
|
|
std::string errorMessage;
|
|
|
|
auto file = openInputFile(inputFilename, &errorMessage);
|
|
|
|
if (!file) {
|
|
|
|
llvm::errs() << errorMessage << "\n";
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::SourceMgr sourceMgr;
|
|
|
|
sourceMgr.AddNewSourceBuffer(std::move(file), llvm::SMLoc());
|
2019-07-03 01:49:17 +08:00
|
|
|
return OwningModuleRef(parseSourceFile(sourceMgr, context));
|
2019-05-14 01:59:04 +08:00
|
|
|
}
|
|
|
|
|
2019-12-19 01:28:48 +08:00
|
|
|
static inline Error make_string_error(const Twine &message) {
|
2019-05-14 01:59:04 +08:00
|
|
|
return llvm::make_error<llvm::StringError>(message.str(),
|
|
|
|
llvm::inconvertibleErrorCode());
|
|
|
|
}
|
|
|
|
|
2020-04-09 09:33:24 +08:00
|
|
|
static Optional<unsigned> getCommandLineOptLevel(Options &options) {
|
2019-12-19 01:28:48 +08:00
|
|
|
Optional<unsigned> optLevel;
|
|
|
|
SmallVector<std::reference_wrapper<llvm::cl::opt<bool>>, 4> optFlags{
|
2020-04-09 09:33:24 +08:00
|
|
|
options.optO0, options.optO1, options.optO2, options.optO3};
|
2019-09-08 00:59:47 +08:00
|
|
|
|
|
|
|
// Determine if there is an optimization flag present.
|
|
|
|
for (unsigned j = 0; j < 4; ++j) {
|
|
|
|
auto &flag = optFlags[j].get();
|
|
|
|
if (flag) {
|
|
|
|
optLevel = j;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return optLevel;
|
|
|
|
}
|
|
|
|
|
2019-08-20 22:45:47 +08:00
|
|
|
// JIT-compile the given module and run "entryPoint" with "args" as arguments.
|
2020-10-28 05:12:47 +08:00
|
|
|
static Error compileAndExecute(Options &options, ModuleOp module,
|
|
|
|
StringRef entryPoint,
|
|
|
|
CompileAndExecuteConfig config, void **args) {
|
2019-09-08 00:59:47 +08:00
|
|
|
Optional<llvm::CodeGenOpt::Level> jitCodeGenOptLevel;
|
2020-04-09 09:33:24 +08:00
|
|
|
if (auto clOptLevel = getCommandLineOptLevel(options))
|
2019-09-08 00:59:47 +08:00
|
|
|
jitCodeGenOptLevel =
|
|
|
|
static_cast<llvm::CodeGenOpt::Level>(clOptLevel.getValue());
|
2020-04-09 09:33:24 +08:00
|
|
|
SmallVector<StringRef, 4> libs(options.clSharedLibs.begin(),
|
|
|
|
options.clSharedLibs.end());
|
[MLIR][mlir-spirv-cpu-runner] A SPIR-V cpu runner prototype
This patch introduces a SPIR-V runner. The aim is to run a gpu
kernel on a CPU via GPU -> SPIRV -> LLVM conversions. This is a first
prototype, so more features will be added in due time.
- Overview
The runner follows similar flow as the other runners in-tree. However,
having converted the kernel to SPIR-V, we encode the bind attributes of
global variables that represent kernel arguments. Then SPIR-V module is
converted to LLVM. On the host side, we emulate passing the data to device
by creating in main module globals with the same symbolic name as in kernel
module. These global variables are later linked with ones from the nested
module. We copy data from kernel arguments to globals, call the kernel
function from nested module and then copy the data back.
- Current state
At the moment, the runner is capable of running 2 modules, nested one in
another. The kernel module must contain exactly one kernel function. Also,
the runner supports rank 1 integer memref types as arguments (to be scaled).
- Enhancement of JitRunner and ExecutionEngine
To translate nested modules to LLVM IR, JitRunner and ExecutionEngine were
altered to take an optional (default to `nullptr`) function reference that
is a custom LLVM IR module builder. This allows to customize LLVM IR module
creation from MLIR modules.
Reviewed By: ftynse, mravishankar
Differential Revision: https://reviews.llvm.org/D86108
2020-10-23 22:46:18 +08:00
|
|
|
auto expectedEngine = mlir::ExecutionEngine::create(
|
2020-10-28 05:12:47 +08:00
|
|
|
module, config.llvmModuleBuilder, config.transformer, jitCodeGenOptLevel,
|
2021-01-08 23:43:54 +08:00
|
|
|
libs);
|
2019-08-20 22:45:47 +08:00
|
|
|
if (!expectedEngine)
|
|
|
|
return expectedEngine.takeError();
|
|
|
|
|
|
|
|
auto engine = std::move(*expectedEngine);
|
2021-01-08 23:43:54 +08:00
|
|
|
if (config.runtimeSymbolMap)
|
|
|
|
engine->registerSymbols(config.runtimeSymbolMap);
|
2020-10-28 05:12:47 +08:00
|
|
|
|
2019-08-20 22:45:47 +08:00
|
|
|
auto expectedFPtr = engine->lookup(entryPoint);
|
|
|
|
if (!expectedFPtr)
|
|
|
|
return expectedFPtr.takeError();
|
2019-08-31 04:01:34 +08:00
|
|
|
|
2020-04-09 09:33:24 +08:00
|
|
|
if (options.dumpObjectFile)
|
|
|
|
engine->dumpToObjectFile(options.objectFilename.empty()
|
|
|
|
? options.inputFilename + ".o"
|
|
|
|
: options.objectFilename);
|
2019-08-31 04:01:34 +08:00
|
|
|
|
2019-08-20 22:45:47 +08:00
|
|
|
void (*fptr)(void **) = *expectedFPtr;
|
|
|
|
(*fptr)(args);
|
|
|
|
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
2020-10-28 05:12:47 +08:00
|
|
|
static Error compileAndExecuteVoidFunction(Options &options, ModuleOp module,
|
|
|
|
StringRef entryPoint,
|
|
|
|
CompileAndExecuteConfig config) {
|
2019-10-10 16:33:33 +08:00
|
|
|
auto mainFunction = module.lookupSymbol<LLVM::LLVMFuncOp>(entryPoint);
|
2020-06-20 03:33:21 +08:00
|
|
|
if (!mainFunction || mainFunction.empty())
|
2019-08-20 22:45:47 +08:00
|
|
|
return make_string_error("entry point not found");
|
|
|
|
void *empty = nullptr;
|
2020-10-28 05:12:47 +08:00
|
|
|
return compileAndExecute(options, module, entryPoint, config, &empty);
|
2019-08-20 22:45:47 +08:00
|
|
|
}
|
|
|
|
|
2019-11-23 08:04:44 +08:00
|
|
|
template <typename Type>
|
|
|
|
Error checkCompatibleReturnType(LLVM::LLVMFuncOp mainFunction);
|
|
|
|
template <>
|
|
|
|
Error checkCompatibleReturnType<int32_t>(LLVM::LLVMFuncOp mainFunction) {
|
2020-12-22 18:22:21 +08:00
|
|
|
auto resultType = mainFunction.getType()
|
|
|
|
.cast<LLVM::LLVMFunctionType>()
|
|
|
|
.getReturnType()
|
[mlir] replace LLVMIntegerType with built-in integer type
The LLVM dialect type system has been closed until now, i.e. did not support
types from other dialects inside containers. While this has had obvious
benefits of deriving from a common base class, it has led to some simple types
being almost identical with the built-in types, namely integer and floating
point types. This in turn has led to a lot of larger-scale complexity: simple
types must still be converted, numerous operations that correspond to LLVM IR
intrinsics are replicated to produce versions operating on either LLVM dialect
or built-in types leading to quasi-duplicate dialects, lowering to the LLVM
dialect is essentially required to be one-shot because of type conversion, etc.
In this light, it is reasonable to trade off some local complexity in the
internal implementation of LLVM dialect types for removing larger-scale system
complexity. Previous commits to the LLVM dialect type system have adapted the
API to support types from other dialects.
Replace LLVMIntegerType with the built-in IntegerType plus additional checks
that such types are signless (these are isolated in a utility function that
replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility
to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice.
Reviewed By: mehdi_amini, silvas, antiagainst
Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
|
|
|
.dyn_cast<IntegerType>();
|
|
|
|
if (!resultType || resultType.getWidth() != 32)
|
[mlir] replace LLVM dialect float types with built-ins
Continue the convergence between LLVM dialect and built-in types by replacing
the bfloat, half, float and double LLVM dialect types with their built-in
counterparts. At the API level, this is a direct replacement. At the syntax
level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively,
to be compatible with the built-in type syntax. The old keywords can still be
parsed but produce a deprecation warning and will be eventually removed.
Depends On D94178
Reviewed By: mehdi_amini, silvas, antiagainst
Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
|
|
|
return make_string_error("only single i32 function result supported");
|
2019-11-23 08:04:44 +08:00
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
template <>
|
|
|
|
Error checkCompatibleReturnType<int64_t>(LLVM::LLVMFuncOp mainFunction) {
|
2020-12-22 18:22:21 +08:00
|
|
|
auto resultType = mainFunction.getType()
|
|
|
|
.cast<LLVM::LLVMFunctionType>()
|
|
|
|
.getReturnType()
|
[mlir] replace LLVMIntegerType with built-in integer type
The LLVM dialect type system has been closed until now, i.e. did not support
types from other dialects inside containers. While this has had obvious
benefits of deriving from a common base class, it has led to some simple types
being almost identical with the built-in types, namely integer and floating
point types. This in turn has led to a lot of larger-scale complexity: simple
types must still be converted, numerous operations that correspond to LLVM IR
intrinsics are replicated to produce versions operating on either LLVM dialect
or built-in types leading to quasi-duplicate dialects, lowering to the LLVM
dialect is essentially required to be one-shot because of type conversion, etc.
In this light, it is reasonable to trade off some local complexity in the
internal implementation of LLVM dialect types for removing larger-scale system
complexity. Previous commits to the LLVM dialect type system have adapted the
API to support types from other dialects.
Replace LLVMIntegerType with the built-in IntegerType plus additional checks
that such types are signless (these are isolated in a utility function that
replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility
to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice.
Reviewed By: mehdi_amini, silvas, antiagainst
Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
|
|
|
.dyn_cast<IntegerType>();
|
|
|
|
if (!resultType || resultType.getWidth() != 64)
|
[mlir] replace LLVM dialect float types with built-ins
Continue the convergence between LLVM dialect and built-in types by replacing
the bfloat, half, float and double LLVM dialect types with their built-in
counterparts. At the API level, this is a direct replacement. At the syntax
level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively,
to be compatible with the built-in type syntax. The old keywords can still be
parsed but produce a deprecation warning and will be eventually removed.
Depends On D94178
Reviewed By: mehdi_amini, silvas, antiagainst
Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
|
|
|
return make_string_error("only single i64 function result supported");
|
2019-11-23 08:04:44 +08:00
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
template <>
|
|
|
|
Error checkCompatibleReturnType<float>(LLVM::LLVMFuncOp mainFunction) {
|
2020-12-22 18:22:21 +08:00
|
|
|
if (!mainFunction.getType()
|
|
|
|
.cast<LLVM::LLVMFunctionType>()
|
|
|
|
.getReturnType()
|
[mlir] replace LLVM dialect float types with built-ins
Continue the convergence between LLVM dialect and built-in types by replacing
the bfloat, half, float and double LLVM dialect types with their built-in
counterparts. At the API level, this is a direct replacement. At the syntax
level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively,
to be compatible with the built-in type syntax. The old keywords can still be
parsed but produce a deprecation warning and will be eventually removed.
Depends On D94178
Reviewed By: mehdi_amini, silvas, antiagainst
Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
|
|
|
.isa<Float32Type>())
|
|
|
|
return make_string_error("only single f32 function result supported");
|
2019-11-23 08:04:44 +08:00
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
template <typename Type>
|
2020-10-28 05:12:47 +08:00
|
|
|
Error compileAndExecuteSingleReturnFunction(Options &options, ModuleOp module,
|
|
|
|
StringRef entryPoint,
|
|
|
|
CompileAndExecuteConfig config) {
|
2019-10-10 16:33:33 +08:00
|
|
|
auto mainFunction = module.lookupSymbol<LLVM::LLVMFuncOp>(entryPoint);
|
|
|
|
if (!mainFunction || mainFunction.isExternal())
|
2019-05-14 01:59:04 +08:00
|
|
|
return make_string_error("entry point not found");
|
|
|
|
|
2020-12-22 18:22:21 +08:00
|
|
|
if (mainFunction.getType().cast<LLVM::LLVMFunctionType>().getNumParams() != 0)
|
2019-05-14 01:59:04 +08:00
|
|
|
return make_string_error("function inputs not supported");
|
|
|
|
|
2019-11-23 08:04:44 +08:00
|
|
|
if (Error error = checkCompatibleReturnType<Type>(mainFunction))
|
|
|
|
return error;
|
2019-05-14 01:59:04 +08:00
|
|
|
|
2019-11-23 08:04:44 +08:00
|
|
|
Type res;
|
2019-05-14 01:59:04 +08:00
|
|
|
struct {
|
|
|
|
void *data;
|
|
|
|
} data;
|
|
|
|
data.data = &res;
|
2020-10-28 05:12:47 +08:00
|
|
|
if (auto error = compileAndExecute(options, module, entryPoint, config,
|
|
|
|
(void **)&data))
|
2019-08-20 22:45:47 +08:00
|
|
|
return error;
|
2019-05-14 01:59:04 +08:00
|
|
|
|
|
|
|
// Intentional printing of the output so we can test.
|
2019-09-26 20:41:26 +08:00
|
|
|
llvm::outs() << res << '\n';
|
2019-11-23 08:04:44 +08:00
|
|
|
|
2019-05-14 01:59:04 +08:00
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
[MLIR][mlir-spirv-cpu-runner] A SPIR-V cpu runner prototype
This patch introduces a SPIR-V runner. The aim is to run a gpu
kernel on a CPU via GPU -> SPIRV -> LLVM conversions. This is a first
prototype, so more features will be added in due time.
- Overview
The runner follows similar flow as the other runners in-tree. However,
having converted the kernel to SPIR-V, we encode the bind attributes of
global variables that represent kernel arguments. Then SPIR-V module is
converted to LLVM. On the host side, we emulate passing the data to device
by creating in main module globals with the same symbolic name as in kernel
module. These global variables are later linked with ones from the nested
module. We copy data from kernel arguments to globals, call the kernel
function from nested module and then copy the data back.
- Current state
At the moment, the runner is capable of running 2 modules, nested one in
another. The kernel module must contain exactly one kernel function. Also,
the runner supports rank 1 integer memref types as arguments (to be scaled).
- Enhancement of JitRunner and ExecutionEngine
To translate nested modules to LLVM IR, JitRunner and ExecutionEngine were
altered to take an optional (default to `nullptr`) function reference that
is a custom LLVM IR module builder. This allows to customize LLVM IR module
creation from MLIR modules.
Reviewed By: ftynse, mravishankar
Differential Revision: https://reviews.llvm.org/D86108
2020-10-23 22:46:18 +08:00
|
|
|
/// Entry point for all CPU runners. Expects the common argc/argv arguments for
|
2020-10-28 05:12:47 +08:00
|
|
|
/// standard C++ main functions.
|
|
|
|
int mlir::JitRunnerMain(int argc, char **argv, JitRunnerConfig config) {
|
2020-04-09 09:33:24 +08:00
|
|
|
// Create the options struct containing the command line options for the
|
|
|
|
// runner. This must come before the command line options are parsed.
|
|
|
|
Options options;
|
2019-05-14 01:59:04 +08:00
|
|
|
llvm::cl::ParseCommandLineOptions(argc, argv, "MLIR CPU execution driver\n");
|
|
|
|
|
2020-04-09 09:33:24 +08:00
|
|
|
Optional<unsigned> optLevel = getCommandLineOptLevel(options);
|
2019-12-19 01:28:48 +08:00
|
|
|
SmallVector<std::reference_wrapper<llvm::cl::opt<bool>>, 4> optFlags{
|
2020-04-09 09:33:24 +08:00
|
|
|
options.optO0, options.optO1, options.optO2, options.optO3};
|
2019-05-14 01:59:04 +08:00
|
|
|
unsigned optCLIPosition = 0;
|
|
|
|
// Determine if there is an optimization flag present, and its CLI position
|
|
|
|
// (optCLIPosition).
|
|
|
|
for (unsigned j = 0; j < 4; ++j) {
|
|
|
|
auto &flag = optFlags[j].get();
|
|
|
|
if (flag) {
|
|
|
|
optCLIPosition = flag.getPosition();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
// Generate vector of pass information, plus the index at which we should
|
|
|
|
// insert any optimization passes in that vector (optPosition).
|
2019-12-19 01:28:48 +08:00
|
|
|
SmallVector<const llvm::PassInfo *, 4> passes;
|
2019-05-14 01:59:04 +08:00
|
|
|
unsigned optPosition = 0;
|
2020-04-09 09:33:24 +08:00
|
|
|
for (unsigned i = 0, e = options.llvmPasses.size(); i < e; ++i) {
|
|
|
|
passes.push_back(options.llvmPasses[i]);
|
|
|
|
if (optCLIPosition < options.llvmPasses.getPosition(i)) {
|
2019-05-14 01:59:04 +08:00
|
|
|
optPosition = i;
|
|
|
|
optCLIPosition = UINT_MAX; // To ensure we never insert again
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-24 04:19:35 +08:00
|
|
|
MLIRContext context;
|
|
|
|
registerAllDialects(context.getDialectRegistry());
|
Separate the Registration from Loading dialects in the Context
This changes the behavior of constructing MLIRContext to no longer load globally
registered dialects on construction. Instead Dialects are only loaded explicitly
on demand:
- the Parser is lazily loading Dialects in the context as it encounters them
during parsing. This is the only purpose for registering dialects and not load
them in the context.
- Passes are expected to declare the dialects they will create entity from
(Operations, Attributes, or Types), and the PassManager is loading Dialects into
the Context when starting a pipeline.
This changes simplifies the configuration of the registration: a compiler only
need to load the dialect for the IR it will emit, and the optimizer is
self-contained and load the required Dialects. For example in the Toy tutorial,
the compiler only needs to load the Toy dialect in the Context, all the others
(linalg, affine, std, LLVM, ...) are automatically loaded depending on the
optimization pipeline enabled.
To adjust to this change, stop using the existing dialect registration: the
global registry will be removed soon.
1) For passes, you need to override the method:
virtual void getDependentDialects(DialectRegistry ®istry) const {}
and registery on the provided registry any dialect that this pass can produce.
Passes defined in TableGen can provide this list in the dependentDialects list
field.
2) For dialects, on construction you can register dependent dialects using the
provided MLIRContext: `context.getOrLoadDialect<DialectName>()`
This is useful if a dialect may canonicalize or have interfaces involving
another dialect.
3) For loading IR, dialect that can be in the input file must be explicitly
registered with the context. `MlirOptMain()` is taking an explicit registry for
this purpose. See how the standalone-opt.cpp example is setup:
mlir::DialectRegistry registry;
registry.insert<mlir::standalone::StandaloneDialect>();
registry.insert<mlir::StandardOpsDialect>();
Only operations from these two dialects can be in the input file. To include all
of the dialects in MLIR Core, you can populate the registry this way:
mlir::registerAllDialects(registry);
4) For `mlir-translate` callback, as well as frontend, Dialects can be loaded in
the context before emitting the IR: context.getOrLoadDialect<ToyDialect>()
Differential Revision: https://reviews.llvm.org/D85622
2020-08-19 04:01:19 +08:00
|
|
|
|
2020-04-09 09:33:24 +08:00
|
|
|
auto m = parseMLIRInput(options.inputFilename, &context);
|
2019-05-14 01:59:04 +08:00
|
|
|
if (!m) {
|
|
|
|
llvm::errs() << "could not parse the input IR\n";
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2020-10-28 05:12:47 +08:00
|
|
|
if (config.mlirTransformer)
|
|
|
|
if (failed(config.mlirTransformer(m.get())))
|
2019-07-04 22:49:52 +08:00
|
|
|
return EXIT_FAILURE;
|
|
|
|
|
2019-08-09 07:02:50 +08:00
|
|
|
auto tmBuilderOrError = llvm::orc::JITTargetMachineBuilder::detectHost();
|
|
|
|
if (!tmBuilderOrError) {
|
|
|
|
llvm::errs() << "Failed to create a JITTargetMachineBuilder for the host\n";
|
|
|
|
return EXIT_FAILURE;
|
|
|
|
}
|
|
|
|
auto tmOrError = tmBuilderOrError->createTargetMachine();
|
|
|
|
if (!tmOrError) {
|
|
|
|
llvm::errs() << "Failed to create a TargetMachine for the host\n";
|
|
|
|
return EXIT_FAILURE;
|
|
|
|
}
|
|
|
|
|
2019-08-06 13:13:56 +08:00
|
|
|
auto transformer = mlir::makeLLVMPassesTransformer(
|
2019-08-09 07:02:50 +08:00
|
|
|
passes, optLevel, /*targetMachine=*/tmOrError->get(), optPosition);
|
2019-08-20 22:45:47 +08:00
|
|
|
|
2020-10-28 05:12:47 +08:00
|
|
|
CompileAndExecuteConfig compileAndExecuteConfig;
|
|
|
|
compileAndExecuteConfig.transformer = transformer;
|
|
|
|
compileAndExecuteConfig.llvmModuleBuilder = config.llvmModuleBuilder;
|
|
|
|
compileAndExecuteConfig.runtimeSymbolMap = config.runtimesymbolMap;
|
|
|
|
|
2019-09-28 00:44:54 +08:00
|
|
|
// Get the function used to compile and execute the module.
|
2020-04-09 09:33:24 +08:00
|
|
|
using CompileAndExecuteFnT =
|
2020-10-28 05:12:47 +08:00
|
|
|
Error (*)(Options &, ModuleOp, StringRef, CompileAndExecuteConfig);
|
2019-09-28 00:44:54 +08:00
|
|
|
auto compileAndExecuteFn =
|
2020-10-07 22:17:35 +08:00
|
|
|
StringSwitch<CompileAndExecuteFnT>(options.mainFuncType.getValue())
|
2019-11-23 08:04:44 +08:00
|
|
|
.Case("i32", compileAndExecuteSingleReturnFunction<int32_t>)
|
|
|
|
.Case("i64", compileAndExecuteSingleReturnFunction<int64_t>)
|
|
|
|
.Case("f32", compileAndExecuteSingleReturnFunction<float>)
|
2019-09-28 00:44:54 +08:00
|
|
|
.Case("void", compileAndExecuteVoidFunction)
|
|
|
|
.Default(nullptr);
|
|
|
|
|
2020-10-28 05:12:47 +08:00
|
|
|
Error error = compileAndExecuteFn
|
|
|
|
? compileAndExecuteFn(options, m.get(),
|
|
|
|
options.mainFuncName.getValue(),
|
|
|
|
compileAndExecuteConfig)
|
|
|
|
: make_string_error("unsupported function type");
|
2019-08-20 22:45:47 +08:00
|
|
|
|
2019-05-14 01:59:04 +08:00
|
|
|
int exitCode = EXIT_SUCCESS;
|
|
|
|
llvm::handleAllErrors(std::move(error),
|
|
|
|
[&exitCode](const llvm::ErrorInfoBase &info) {
|
|
|
|
llvm::errs() << "Error: ";
|
|
|
|
info.log(llvm::errs());
|
|
|
|
llvm::errs() << '\n';
|
|
|
|
exitCode = EXIT_FAILURE;
|
|
|
|
});
|
|
|
|
|
|
|
|
return exitCode;
|
|
|
|
}
|