2003-06-20 17:49:04 +02:00
|
|
|
//===-- llc.cpp - Implement the LLVM Native Code Generator ----------------===//
|
2005-04-22 02:00:37 +02:00
|
|
|
//
|
2019-01-19 09:50:56 +01:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2005-04-22 02:00:37 +02:00
|
|
|
//
|
2003-10-20 19:47:21 +02:00
|
|
|
//===----------------------------------------------------------------------===//
|
2001-09-08 00:20:50 +02:00
|
|
|
//
|
2004-03-16 22:47:20 +01:00
|
|
|
// This is the llc code generator driver. It provides a convenient
|
2005-04-22 02:00:37 +02:00
|
|
|
// command-line interface for generating native assembly-language code
|
2007-07-05 19:07:56 +02:00
|
|
|
// or C code, given LLVM bitcode.
|
2001-09-08 00:20:50 +02:00
|
|
|
//
|
2001-10-04 03:40:53 +02:00
|
|
|
//===----------------------------------------------------------------------===//
|
2001-07-21 14:42:29 +02:00
|
|
|
|
2015-03-01 22:28:53 +01:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2009-08-03 06:03:51 +02:00
|
|
|
#include "llvm/ADT/Triple.h"
|
2015-01-15 03:16:27 +01:00
|
|
|
#include "llvm/Analysis/TargetLibraryInfo.h"
|
2020-03-04 00:47:43 +01:00
|
|
|
#include "llvm/CodeGen/CommandFlags.h"
|
2009-08-03 06:03:51 +02:00
|
|
|
#include "llvm/CodeGen/LinkAllAsmWriterComponents.h"
|
|
|
|
#include "llvm/CodeGen/LinkAllCodegenComponents.h"
|
2015-05-27 20:02:19 +02:00
|
|
|
#include "llvm/CodeGen/MIRParser/MIRParser.h"
|
2016-05-10 03:32:44 +02:00
|
|
|
#include "llvm/CodeGen/MachineFunctionPass.h"
|
2016-05-10 04:09:32 +02:00
|
|
|
#include "llvm/CodeGen/MachineModuleInfo.h"
|
2016-05-10 05:21:59 +02:00
|
|
|
#include "llvm/CodeGen/TargetPassConfig.h"
|
2017-11-17 02:07:10 +01:00
|
|
|
#include "llvm/CodeGen/TargetSubtargetInfo.h"
|
2018-01-30 23:32:39 +01:00
|
|
|
#include "llvm/IR/AutoUpgrade.h"
|
2013-01-02 12:36:10 +01:00
|
|
|
#include "llvm/IR/DataLayout.h"
|
2016-05-16 16:28:02 +02:00
|
|
|
#include "llvm/IR/DiagnosticInfo.h"
|
|
|
|
#include "llvm/IR/DiagnosticPrinter.h"
|
2014-01-13 09:04:33 +01:00
|
|
|
#include "llvm/IR/IRPrintingPasses.h"
|
|
|
|
#include "llvm/IR/LLVMContext.h"
|
2019-10-28 22:53:31 +01:00
|
|
|
#include "llvm/IR/LLVMRemarkStreamer.h"
|
2015-02-13 11:01:29 +01:00
|
|
|
#include "llvm/IR/LegacyPassManager.h"
|
2013-01-02 12:36:10 +01:00
|
|
|
#include "llvm/IR/Module.h"
|
2015-03-27 23:04:28 +01:00
|
|
|
#include "llvm/IR/Verifier.h"
|
2013-03-26 03:25:37 +01:00
|
|
|
#include "llvm/IRReader/IRReader.h"
|
Sink all InitializePasses.h includes
This file lists every pass in LLVM, and is included by Pass.h, which is
very popular. Every time we add, remove, or rename a pass in LLVM, it
caused lots of recompilation.
I found this fact by looking at this table, which is sorted by the
number of times a file was changed over the last 100,000 git commits
multiplied by the number of object files that depend on it in the
current checkout:
recompiles touches affected_files header
342380 95 3604 llvm/include/llvm/ADT/STLExtras.h
314730 234 1345 llvm/include/llvm/InitializePasses.h
307036 118 2602 llvm/include/llvm/ADT/APInt.h
213049 59 3611 llvm/include/llvm/Support/MathExtras.h
170422 47 3626 llvm/include/llvm/Support/Compiler.h
162225 45 3605 llvm/include/llvm/ADT/Optional.h
158319 63 2513 llvm/include/llvm/ADT/Triple.h
140322 39 3598 llvm/include/llvm/ADT/StringRef.h
137647 59 2333 llvm/include/llvm/Support/Error.h
131619 73 1803 llvm/include/llvm/Support/FileSystem.h
Before this change, touching InitializePasses.h would cause 1345 files
to recompile. After this change, touching it only causes 550 compiles in
an incremental rebuild.
Reviewers: bkramer, asbirlea, bollu, jdoerfert
Differential Revision: https://reviews.llvm.org/D70211
2019-11-13 22:15:01 +01:00
|
|
|
#include "llvm/InitializePasses.h"
|
2011-06-29 03:14:12 +02:00
|
|
|
#include "llvm/MC/SubtargetFeature.h"
|
2012-12-04 11:44:52 +01:00
|
|
|
#include "llvm/Pass.h"
|
2020-11-17 19:37:59 +01:00
|
|
|
#include "llvm/Remarks/HotnessThresholdParser.h"
|
2004-09-02 00:55:40 +02:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
2010-01-05 02:30:21 +01:00
|
|
|
#include "llvm/Support/Debug.h"
|
2014-04-30 01:26:49 +02:00
|
|
|
#include "llvm/Support/FileSystem.h"
|
2009-07-14 22:18:05 +02:00
|
|
|
#include "llvm/Support/FormattedStream.h"
|
2012-12-04 11:44:52 +01:00
|
|
|
#include "llvm/Support/Host.h"
|
2018-04-13 20:26:06 +02:00
|
|
|
#include "llvm/Support/InitLLVM.h"
|
2006-12-06 02:18:01 +01:00
|
|
|
#include "llvm/Support/ManagedStatic.h"
|
2004-09-02 00:55:40 +02:00
|
|
|
#include "llvm/Support/PluginLoader.h"
|
2013-03-26 03:25:37 +01:00
|
|
|
#include "llvm/Support/SourceMgr.h"
|
2011-08-24 20:08:43 +02:00
|
|
|
#include "llvm/Support/TargetRegistry.h"
|
|
|
|
#include "llvm/Support/TargetSelect.h"
|
2012-12-04 11:44:52 +01:00
|
|
|
#include "llvm/Support/ToolOutputFile.h"
|
2018-06-23 18:51:10 +02:00
|
|
|
#include "llvm/Support/WithColor.h"
|
2020-03-20 18:35:19 +01:00
|
|
|
#include "llvm/Target/TargetLoweringObjectFile.h"
|
2009-08-03 06:03:51 +02:00
|
|
|
#include "llvm/Target/TargetMachine.h"
|
2015-12-04 22:56:46 +01:00
|
|
|
#include "llvm/Transforms/Utils/Cloning.h"
|
2004-07-04 14:20:55 +02:00
|
|
|
#include <memory>
|
2003-11-11 23:41:34 +01:00
|
|
|
using namespace llvm;
|
|
|
|
|
2020-03-04 00:47:43 +01:00
|
|
|
static codegen::RegisterCodeGenFlags CGF;
|
|
|
|
|
2002-09-16 18:35:34 +02:00
|
|
|
// General options for llc. Other pass-specific options are specified
|
|
|
|
// within the corresponding llc passes, and target-specific options
|
|
|
|
// and back-end code generation options are specified with the target machine.
|
2005-04-22 02:00:37 +02:00
|
|
|
//
|
2003-04-25 07:26:11 +02:00
|
|
|
static cl::opt<std::string>
|
2007-07-05 19:07:56 +02:00
|
|
|
InputFilename(cl::Positional, cl::desc("<input bitcode>"), cl::init("-"));
|
2002-07-22 04:10:13 +02:00
|
|
|
|
2017-06-06 22:06:57 +02:00
|
|
|
static cl::opt<std::string>
|
|
|
|
InputLanguage("x", cl::desc("Input language ('ir' or 'mir')"));
|
|
|
|
|
2003-04-25 07:26:11 +02:00
|
|
|
static cl::opt<std::string>
|
2002-07-22 04:10:13 +02:00
|
|
|
OutputFilename("o", cl::desc("Output filename"), cl::value_desc("filename"));
|
|
|
|
|
2018-05-21 22:16:41 +02:00
|
|
|
static cl::opt<std::string>
|
|
|
|
SplitDwarfOutputFile("split-dwarf-output",
|
|
|
|
cl::desc(".dwo output filename"),
|
|
|
|
cl::value_desc("filename"));
|
|
|
|
|
2012-11-30 22:42:47 +01:00
|
|
|
static cl::opt<unsigned>
|
|
|
|
TimeCompilations("time-compilations", cl::Hidden, cl::init(1u),
|
|
|
|
cl::value_desc("N"),
|
|
|
|
cl::desc("Repeat compilation N times for timing"));
|
|
|
|
|
Add -fbinutils-version= to gate ELF features on the specified binutils version
There are two use cases.
Assembler
We have accrued some code gated on MCAsmInfo::useIntegratedAssembler(). Some
features are supported by latest GNU as, but we have to use
MCAsmInfo::useIntegratedAs() because the newer versions have not been widely
adopted (e.g. SHF_LINK_ORDER 'o' and 'unique' linkage in 2.35, --compress-debug-sections= in 2.26).
Linker
We want to use features supported only by LLD or very new GNU ld, or don't want
to work around older GNU ld. We currently can't represent that "we don't care
about old GNU ld". You can find such workarounds in a few other places, e.g.
Mips/MipsAsmprinter.cpp PowerPC/PPCTOCRegDeps.cpp X86/X86MCInstrLower.cpp
AArch64 TLS workaround for R_AARCH64_TLSLD_MOVW_DTPREL_* (PR ld/18276),
R_AARCH64_TLSLE_LDST8_TPREL_LO12 (https://bugs.llvm.org/show_bug.cgi?id=36727 https://sourceware.org/bugzilla/show_bug.cgi?id=22969)
Mixed SHF_LINK_ORDER and non-SHF_LINK_ORDER components (supported by LLD in D84001;
GNU ld feature request https://sourceware.org/bugzilla/show_bug.cgi?id=16833 may take a while before available).
This feature allows to garbage collect some unused sections (e.g. fragmented .gcc_except_table).
This patch adds `-fbinutils-version=` to clang and `-binutils-version` to llc.
It changes one codegen place in SHF_MERGE to demonstrate its usage.
`-fbinutils-version=2.35` means the produced object file does not care about GNU
ld<2.35 compatibility. When `-fno-integrated-as` is specified, the produced
assembly can be consumed by GNU as>=2.35, but older versions may not work.
`-fbinutils-version=none` means that we can use all ELF features, regardless of
GNU as/ld support.
Both clang and llc need `parseBinutilsVersion`. Such command line parsing is
usually implemented in `llvm/lib/CodeGen/CommandFlags.cpp` (LLVMCodeGen),
however, ClangCodeGen does not depend on LLVMCodeGen. So I add
`parseBinutilsVersion` to `llvm/lib/Target/TargetMachine.cpp` (LLVMTarget).
Differential Revision: https://reviews.llvm.org/D85474
2021-01-26 21:28:23 +01:00
|
|
|
static cl::opt<std::string>
|
|
|
|
BinutilsVersion("binutils-version", cl::Hidden,
|
|
|
|
cl::desc("Produced object files can use all ELF features "
|
|
|
|
"supported by this binutils version and newer."
|
|
|
|
"If -no-integrated-as is specified, the generated "
|
|
|
|
"assembly will consider GNU as support."
|
|
|
|
"'none' means that all ELF features can be used, "
|
|
|
|
"regardless of binutils support"));
|
|
|
|
|
2014-02-21 04:13:54 +01:00
|
|
|
static cl::opt<bool>
|
|
|
|
NoIntegratedAssembler("no-integrated-as", cl::Hidden,
|
|
|
|
cl::desc("Disable integrated assembler"));
|
|
|
|
|
2016-07-11 14:42:14 +02:00
|
|
|
static cl::opt<bool>
|
2016-07-13 16:20:41 +02:00
|
|
|
PreserveComments("preserve-as-comments", cl::Hidden,
|
2016-07-12 17:32:36 +02:00
|
|
|
cl::desc("Preserve Comments in outputted assembly"),
|
|
|
|
cl::init(true));
|
2016-07-11 14:42:14 +02:00
|
|
|
|
2009-05-05 01:05:19 +02:00
|
|
|
// Determine optimization level.
|
2009-04-30 01:29:43 +02:00
|
|
|
static cl::opt<char>
|
2009-04-29 02:15:41 +02:00
|
|
|
OptLevel("O",
|
2009-05-05 01:05:19 +02:00
|
|
|
cl::desc("Optimization level. [-O0, -O1, -O2, or -O3] "
|
|
|
|
"(default = '-O2')"),
|
2009-04-29 02:15:41 +02:00
|
|
|
cl::Prefix,
|
|
|
|
cl::ZeroOrMore,
|
2009-04-30 01:29:43 +02:00
|
|
|
cl::init(' '));
|
2005-11-08 03:12:17 +01:00
|
|
|
|
2005-12-16 05:59:57 +01:00
|
|
|
static cl::opt<std::string>
|
2005-12-16 06:19:55 +01:00
|
|
|
TargetTriple("mtriple", cl::desc("Override target triple for module"));
|
2005-11-08 03:12:17 +01:00
|
|
|
|
2017-04-22 01:35:26 +02:00
|
|
|
static cl::opt<std::string> SplitDwarfFile(
|
|
|
|
"split-dwarf-file",
|
|
|
|
cl::desc(
|
|
|
|
"Specify the name of the .dwo file to encode in the DWARF output"));
|
|
|
|
|
2014-05-21 23:05:05 +02:00
|
|
|
static cl::opt<bool> NoVerify("disable-verify", cl::Hidden,
|
|
|
|
cl::desc("Do not verify input module"));
|
2005-07-28 04:25:30 +02:00
|
|
|
|
2014-05-21 23:05:05 +02:00
|
|
|
static cl::opt<bool> DisableSimplifyLibCalls("disable-simplify-libcalls",
|
|
|
|
cl::desc("Disable simplify-libcalls"));
|
2012-08-21 18:15:24 +02:00
|
|
|
|
2014-05-21 23:05:09 +02:00
|
|
|
static cl::opt<bool> ShowMCEncoding("show-mc-encoding", cl::Hidden,
|
|
|
|
cl::desc("Show encoding in .s output"));
|
|
|
|
|
2021-07-13 02:44:02 +02:00
|
|
|
static cl::opt<bool>
|
|
|
|
DwarfDirectory("dwarf-directory", cl::Hidden,
|
|
|
|
cl::desc("Use .file directives with an explicit directory"),
|
|
|
|
cl::init(true));
|
2014-05-21 23:05:09 +02:00
|
|
|
|
|
|
|
static cl::opt<bool> AsmVerbose("asm-verbose",
|
|
|
|
cl::desc("Add comments to directives."),
|
|
|
|
cl::init(true));
|
|
|
|
|
2015-12-04 22:56:46 +01:00
|
|
|
static cl::opt<bool>
|
|
|
|
CompileTwice("compile-twice", cl::Hidden,
|
|
|
|
cl::desc("Run everything twice, re-using the same pass "
|
2015-12-07 20:21:39 +01:00
|
|
|
"manager and verify the result is the same."),
|
2015-12-04 22:56:46 +01:00
|
|
|
cl::init(false));
|
|
|
|
|
Add a flag to the LLVMContext to disable name for Value other than GlobalValue
Summary:
This is intended to be a performance flag, on the same level as clang
cc1 option "--disable-free". LLVM will never initialize it by default,
it will be up to the client creating the LLVMContext to request this
behavior. Clang will do it by default in Release build (just like
--disable-free).
"opt" and "llc" can opt-in using -disable-named-value command line
option.
When performing LTO on llvm-tblgen, the initial merging of IR peaks
at 92MB without this patch, and 86MB after this patch,setNameImpl()
drops from 6.5MB to 0.5MB.
The total link time goes from ~29.5s to ~27.8s.
Compared to a compile-time flag (like the IRBuilder one), it performs
very close. I profiled on SROA and obtain these results:
420ms with IRBuilder that preserve name
372ms with IRBuilder that strip name
375ms with IRBuilder that preserve name, and a runtime flag to strip
Reviewers: chandlerc, dexonsmith, bogner
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D17946
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 263086
2016-03-10 02:28:54 +01:00
|
|
|
static cl::opt<bool> DiscardValueNames(
|
|
|
|
"discard-value-names",
|
|
|
|
cl::desc("Discard names from Value (other than GlobalValue)."),
|
|
|
|
cl::init(false), cl::Hidden);
|
|
|
|
|
2017-01-05 06:56:39 +01:00
|
|
|
static cl::list<std::string> IncludeDirs("I", cl::desc("include search path"));
|
|
|
|
|
2019-06-14 18:20:51 +02:00
|
|
|
static cl::opt<bool> RemarksWithHotness(
|
2017-01-26 00:55:59 +01:00
|
|
|
"pass-remarks-with-hotness",
|
|
|
|
cl::desc("With PGO, include profile count in optimization remarks"),
|
|
|
|
cl::Hidden);
|
|
|
|
|
2020-11-17 19:37:59 +01:00
|
|
|
static cl::opt<Optional<uint64_t>, false, remarks::HotnessThresholdParser>
|
|
|
|
RemarksHotnessThreshold(
|
|
|
|
"pass-remarks-hotness-threshold",
|
|
|
|
cl::desc("Minimum profile count required for "
|
|
|
|
"an optimization remark to be output. "
|
|
|
|
"Use 'auto' to apply the threshold from profile summary."),
|
|
|
|
cl::value_desc("N or 'auto'"), cl::init(0), cl::Hidden);
|
2017-07-01 01:14:53 +02:00
|
|
|
|
2017-01-26 01:39:51 +01:00
|
|
|
static cl::opt<std::string>
|
|
|
|
RemarksFilename("pass-remarks-output",
|
2019-06-14 18:20:51 +02:00
|
|
|
cl::desc("Output filename for pass remarks"),
|
2017-01-26 01:39:51 +01:00
|
|
|
cl::value_desc("filename"));
|
|
|
|
|
2019-03-12 22:22:27 +01:00
|
|
|
static cl::opt<std::string>
|
|
|
|
RemarksPasses("pass-remarks-filter",
|
|
|
|
cl::desc("Only record optimization remarks from passes whose "
|
|
|
|
"names match the given regular expression"),
|
|
|
|
cl::value_desc("regex"));
|
|
|
|
|
2019-06-17 18:06:00 +02:00
|
|
|
static cl::opt<std::string> RemarksFormat(
|
|
|
|
"pass-remarks-format",
|
|
|
|
cl::desc("The format used for serializing remarks (default: YAML)"),
|
|
|
|
cl::value_desc("format"), cl::init("yaml"));
|
|
|
|
|
2016-06-10 02:52:10 +02:00
|
|
|
namespace {
|
|
|
|
static ManagedStatic<std::vector<std::string>> RunPassNames;
|
|
|
|
|
|
|
|
struct RunPassOption {
|
|
|
|
void operator=(const std::string &Val) const {
|
|
|
|
if (Val.empty())
|
|
|
|
return;
|
|
|
|
SmallVector<StringRef, 8> PassNames;
|
|
|
|
StringRef(Val).split(PassNames, ',', -1, false);
|
|
|
|
for (auto PassName : PassNames)
|
2020-01-28 20:23:46 +01:00
|
|
|
RunPassNames->push_back(std::string(PassName));
|
2016-06-10 02:52:10 +02:00
|
|
|
}
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
static RunPassOption RunPassOpt;
|
|
|
|
|
|
|
|
static cl::opt<RunPassOption, true, cl::parser<std::string>> RunPass(
|
|
|
|
"run-pass",
|
|
|
|
cl::desc("Run compiler only for specified passes (comma separated list)"),
|
|
|
|
cl::value_desc("pass-name"), cl::ZeroOrMore, cl::location(RunPassOpt));
|
|
|
|
|
2014-05-21 23:05:09 +02:00
|
|
|
static int compileModule(char **, LLVMContext &);
|
2012-11-30 22:42:47 +01:00
|
|
|
|
2021-01-27 00:33:37 +01:00
|
|
|
LLVM_ATTRIBUTE_NORETURN static void reportError(Twine Msg,
|
|
|
|
StringRef Filename = "") {
|
|
|
|
SmallString<256> Prefix;
|
|
|
|
if (!Filename.empty()) {
|
|
|
|
if (Filename == "-")
|
|
|
|
Filename = "<stdin>";
|
|
|
|
("'" + Twine(Filename) + "': ").toStringRef(Prefix);
|
|
|
|
}
|
|
|
|
WithColor::error(errs(), "llc") << Prefix << Msg << "\n";
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
LLVM_ATTRIBUTE_NORETURN static void reportError(Error Err, StringRef Filename) {
|
|
|
|
assert(Err);
|
|
|
|
handleAllErrors(createFileError(Filename, std::move(Err)),
|
|
|
|
[&](const ErrorInfoBase &EI) { reportError(EI.message()); });
|
|
|
|
llvm_unreachable("reportError() should not return");
|
|
|
|
}
|
|
|
|
|
2017-09-23 03:03:17 +02:00
|
|
|
static std::unique_ptr<ToolOutputFile> GetOutputStream(const char *TargetName,
|
|
|
|
Triple::OSType OS,
|
|
|
|
const char *ProgName) {
|
2010-08-18 19:55:15 +02:00
|
|
|
// If we don't yet have an output filename, make one.
|
|
|
|
if (OutputFilename.empty()) {
|
|
|
|
if (InputFilename == "-")
|
|
|
|
OutputFilename = "-";
|
|
|
|
else {
|
2014-08-30 18:48:22 +02:00
|
|
|
// If InputFilename ends in .bc or .ll, remove it.
|
|
|
|
StringRef IFN = InputFilename;
|
|
|
|
if (IFN.endswith(".bc") || IFN.endswith(".ll"))
|
2020-01-28 20:23:46 +01:00
|
|
|
OutputFilename = std::string(IFN.drop_back(3));
|
2015-05-27 20:02:19 +02:00
|
|
|
else if (IFN.endswith(".mir"))
|
2020-01-28 20:23:46 +01:00
|
|
|
OutputFilename = std::string(IFN.drop_back(4));
|
2014-08-30 18:48:22 +02:00
|
|
|
else
|
2020-01-28 20:23:46 +01:00
|
|
|
OutputFilename = std::string(IFN);
|
2010-08-18 19:55:15 +02:00
|
|
|
|
2020-03-04 00:47:43 +01:00
|
|
|
switch (codegen::getFileType()) {
|
2019-11-14 00:17:46 +01:00
|
|
|
case CGFT_AssemblyFile:
|
2010-08-18 19:55:15 +02:00
|
|
|
if (TargetName[0] == 'c') {
|
|
|
|
if (TargetName[1] == 0)
|
|
|
|
OutputFilename += ".cbe.c";
|
|
|
|
else if (TargetName[1] == 'p' && TargetName[2] == 'p')
|
|
|
|
OutputFilename += ".cpp";
|
|
|
|
else
|
|
|
|
OutputFilename += ".s";
|
|
|
|
} else
|
|
|
|
OutputFilename += ".s";
|
|
|
|
break;
|
2019-11-14 00:17:46 +01:00
|
|
|
case CGFT_ObjectFile:
|
2010-08-18 19:55:15 +02:00
|
|
|
if (OS == Triple::Win32)
|
|
|
|
OutputFilename += ".obj";
|
|
|
|
else
|
|
|
|
OutputFilename += ".o";
|
|
|
|
break;
|
2019-11-14 00:17:46 +01:00
|
|
|
case CGFT_Null:
|
2020-10-13 02:28:48 +02:00
|
|
|
OutputFilename = "-";
|
2010-08-18 19:55:15 +02:00
|
|
|
break;
|
|
|
|
}
|
2008-08-21 17:33:45 +02:00
|
|
|
}
|
2006-09-04 06:14:57 +02:00
|
|
|
}
|
|
|
|
|
2010-08-18 19:55:15 +02:00
|
|
|
// Decide if we need "binary" output.
|
2008-11-13 06:01:07 +01:00
|
|
|
bool Binary = false;
|
2020-03-04 00:47:43 +01:00
|
|
|
switch (codegen::getFileType()) {
|
2019-11-14 00:17:46 +01:00
|
|
|
case CGFT_AssemblyFile:
|
2006-09-04 06:14:57 +02:00
|
|
|
break;
|
2019-11-14 00:17:46 +01:00
|
|
|
case CGFT_ObjectFile:
|
|
|
|
case CGFT_Null:
|
2008-11-13 06:01:07 +01:00
|
|
|
Binary = true;
|
2006-09-04 06:14:57 +02:00
|
|
|
break;
|
|
|
|
}
|
2009-01-16 07:53:46 +01:00
|
|
|
|
2010-08-18 19:55:15 +02:00
|
|
|
// Open the file.
|
2014-08-25 20:16:47 +02:00
|
|
|
std::error_code EC;
|
2019-08-05 07:43:48 +02:00
|
|
|
sys::fs::OpenFlags OpenFlags = sys::fs::OF_None;
|
2014-02-24 19:20:12 +01:00
|
|
|
if (!Binary)
|
2021-04-06 13:22:41 +02:00
|
|
|
OpenFlags |= sys::fs::OF_TextWithCRLF;
|
2019-08-15 17:54:37 +02:00
|
|
|
auto FDOut = std::make_unique<ToolOutputFile>(OutputFilename, EC, OpenFlags);
|
2014-08-25 20:16:47 +02:00
|
|
|
if (EC) {
|
2021-01-27 00:33:37 +01:00
|
|
|
reportError(EC.message());
|
2014-04-25 06:24:47 +02:00
|
|
|
return nullptr;
|
2006-09-04 06:14:57 +02:00
|
|
|
}
|
2009-01-16 07:53:46 +01:00
|
|
|
|
2010-09-01 16:20:41 +02:00
|
|
|
return FDOut;
|
2006-09-04 06:14:57 +02:00
|
|
|
}
|
2001-09-18 19:04:18 +02:00
|
|
|
|
2017-09-15 22:10:09 +02:00
|
|
|
struct LLCDiagnosticHandler : public DiagnosticHandler {
|
|
|
|
bool *HasError;
|
|
|
|
LLCDiagnosticHandler(bool *HasErrorPtr) : HasError(HasErrorPtr) {}
|
|
|
|
bool handleDiagnostics(const DiagnosticInfo &DI) override {
|
2021-02-23 18:47:15 +01:00
|
|
|
if (DI.getKind() == llvm::DK_SrcMgr) {
|
|
|
|
const auto &DISM = cast<DiagnosticInfoSrcMgr>(DI);
|
|
|
|
const SMDiagnostic &SMD = DISM.getSMDiag();
|
|
|
|
|
|
|
|
if (SMD.getKind() == SourceMgr::DK_Error)
|
|
|
|
*HasError = true;
|
|
|
|
|
|
|
|
SMD.print(nullptr, errs());
|
|
|
|
|
|
|
|
// For testing purposes, we print the LocCookie here.
|
|
|
|
if (DISM.isInlineAsmDiag() && DISM.getLocCookie())
|
|
|
|
WithColor::note() << "!srcloc = " << DISM.getLocCookie() << "\n";
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-09-15 22:10:09 +02:00
|
|
|
if (DI.getSeverity() == DS_Error)
|
|
|
|
*HasError = true;
|
|
|
|
|
|
|
|
if (auto *Remark = dyn_cast<DiagnosticInfoOptimizationBase>(&DI))
|
|
|
|
if (!Remark->isEnabled())
|
|
|
|
return true;
|
|
|
|
|
|
|
|
DiagnosticPrinterRawOStream DP(errs());
|
|
|
|
errs() << LLVMContext::getDiagnosticMessagePrefix(DI.getSeverity()) << ": ";
|
|
|
|
DI.print(DP);
|
|
|
|
errs() << "\n";
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
};
|
2016-05-16 16:28:02 +02:00
|
|
|
|
2003-06-20 17:49:04 +02:00
|
|
|
// main - Entry point for the llc compiler.
|
|
|
|
//
|
|
|
|
int main(int argc, char **argv) {
|
2018-04-13 20:26:06 +02:00
|
|
|
InitLLVM X(argc, argv);
|
2010-01-05 02:30:21 +01:00
|
|
|
|
|
|
|
// Enable debug stream buffering.
|
|
|
|
EnableDebugBuffering = true;
|
|
|
|
|
2016-04-14 23:59:01 +02:00
|
|
|
LLVMContext Context;
|
2004-07-11 06:03:24 +02:00
|
|
|
|
2009-09-03 07:47:22 +02:00
|
|
|
// Initialize targets first, so that --version shows registered targets.
|
2009-06-17 18:42:19 +02:00
|
|
|
InitializeAllTargets();
|
2011-07-22 23:58:54 +02:00
|
|
|
InitializeAllTargetMCs();
|
2009-06-17 18:42:19 +02:00
|
|
|
InitializeAllAsmPrinters();
|
add .o file writing for inline asm in llc. Here's a silly
demo:
$ clang asm.c -S -o - -emit-llvm | llc -filetype=obj -o t.o
<inline asm>:1:2: error: unrecognized instruction
abc incl %eax
^
LLVM ERROR: Error parsing inline asm
Only problem seems to be that the parser finalizes OutStreamer
at the end of the first inline asm, which isn't what we want.
For example:
$ cat asm.c
int foo(int X) {
__asm__ ("incl %0" : "+r" (X));
return X;
}
$ clang asm.c -S -o - -emit-llvm | llc
...
subq $8, %rsp
movl %edi, (%rsp)
movl %edi, %eax
## InlineAsm Start
incl %eax
## InlineAsm End
movl %eax, (%rsp)
movl %eax, 4(%rsp)
addq $8, %rsp
ret
$ clang asm.c -S -o - -emit-llvm | llc -filetype=obj -o t.o
$ otool -tv t.o
t.o:
(__TEXT,__text) section
_foo:
0000000000000000 subq $0x08,%rsp
0000000000000004 movl %edi,(%rsp)
0000000000000007 movl %edi,%eax
0000000000000009 incl %eax
$
don't stop at inc!
llvm-svn: 100491
2010-04-06 01:11:24 +02:00
|
|
|
InitializeAllAsmParsers();
|
2009-07-16 04:04:54 +02:00
|
|
|
|
2012-07-02 21:48:45 +02:00
|
|
|
// Initialize codegen and IR passes used by llc so that the -print-after,
|
|
|
|
// -print-before, and -stop-after options work.
|
|
|
|
PassRegistry *Registry = PassRegistry::getPassRegistry();
|
|
|
|
initializeCore(*Registry);
|
|
|
|
initializeCodeGen(*Registry);
|
|
|
|
initializeLoopStrengthReducePass(*Registry);
|
|
|
|
initializeLowerIntrinsicsPass(*Registry);
|
2017-11-14 22:09:45 +01:00
|
|
|
initializeEntryExitInstrumenterPass(*Registry);
|
|
|
|
initializePostInlineEntryExitInstrumenterPass(*Registry);
|
2016-07-08 05:32:49 +02:00
|
|
|
initializeUnreachableBlockElimLegacyPassPass(*Registry);
|
2016-12-07 00:49:58 +01:00
|
|
|
initializeConstantHoistingLegacyPassPass(*Registry);
|
2017-01-17 06:11:25 +01:00
|
|
|
initializeScalarOpts(*Registry);
|
|
|
|
initializeVectorization(*Registry);
|
2020-12-07 04:51:23 +01:00
|
|
|
initializeScalarizeMaskedMemIntrinLegacyPassPass(*Registry);
|
2017-05-10 11:42:49 +02:00
|
|
|
initializeExpandReductionsPass(*Registry);
|
2021-04-30 13:43:48 +02:00
|
|
|
initializeExpandVectorPredicationPass(*Registry);
|
2019-06-07 09:35:30 +02:00
|
|
|
initializeHardwareLoopsPass(*Registry);
|
2020-03-28 12:13:35 +01:00
|
|
|
initializeTransformUtils(*Registry);
|
2021-02-12 18:22:28 +01:00
|
|
|
initializeReplaceWithVeclibLegacyPass(*Registry);
|
2012-06-26 23:33:36 +02:00
|
|
|
|
2017-06-03 01:01:42 +02:00
|
|
|
// Initialize debugging passes.
|
|
|
|
initializeScavengerTestPass(*Registry);
|
|
|
|
|
2011-07-22 09:50:48 +02:00
|
|
|
// Register the target printer for --version.
|
|
|
|
cl::AddExtraVersionPrinter(TargetRegistry::printRegisteredTargetsForVersion);
|
|
|
|
|
2009-07-16 04:04:54 +02:00
|
|
|
cl::ParseCommandLineOptions(argc, argv, "llvm system compiler\n");
|
2011-04-05 20:41:31 +02:00
|
|
|
|
Add a flag to the LLVMContext to disable name for Value other than GlobalValue
Summary:
This is intended to be a performance flag, on the same level as clang
cc1 option "--disable-free". LLVM will never initialize it by default,
it will be up to the client creating the LLVMContext to request this
behavior. Clang will do it by default in Release build (just like
--disable-free).
"opt" and "llc" can opt-in using -disable-named-value command line
option.
When performing LTO on llvm-tblgen, the initial merging of IR peaks
at 92MB without this patch, and 86MB after this patch,setNameImpl()
drops from 6.5MB to 0.5MB.
The total link time goes from ~29.5s to ~27.8s.
Compared to a compile-time flag (like the IRBuilder one), it performs
very close. I profiled on SROA and obtain these results:
420ms with IRBuilder that preserve name
372ms with IRBuilder that strip name
375ms with IRBuilder that preserve name, and a runtime flag to strip
Reviewers: chandlerc, dexonsmith, bogner
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D17946
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 263086
2016-03-10 02:28:54 +01:00
|
|
|
Context.setDiscardValueNames(DiscardValueNames);
|
|
|
|
|
2016-05-16 16:28:02 +02:00
|
|
|
// Set a diagnostic handler that doesn't exit on the first error
|
|
|
|
bool HasError = false;
|
2017-09-15 22:10:09 +02:00
|
|
|
Context.setDiagnosticHandler(
|
2019-08-15 17:54:37 +02:00
|
|
|
std::make_unique<LLCDiagnosticHandler>(&HasError));
|
2017-02-03 12:14:39 +01:00
|
|
|
|
2019-06-14 18:20:51 +02:00
|
|
|
Expected<std::unique_ptr<ToolOutputFile>> RemarksFileOrErr =
|
2019-10-28 22:53:31 +01:00
|
|
|
setupLLVMOptimizationRemarks(Context, RemarksFilename, RemarksPasses,
|
|
|
|
RemarksFormat, RemarksWithHotness,
|
|
|
|
RemarksHotnessThreshold);
|
2021-01-27 00:33:37 +01:00
|
|
|
if (Error E = RemarksFileOrErr.takeError())
|
|
|
|
reportError(std::move(E), RemarksFilename);
|
2019-06-14 18:20:51 +02:00
|
|
|
std::unique_ptr<ToolOutputFile> RemarksFile = std::move(*RemarksFileOrErr);
|
2017-01-26 01:39:51 +01:00
|
|
|
|
2021-01-27 00:33:37 +01:00
|
|
|
if (InputLanguage != "" && InputLanguage != "ir" && InputLanguage != "mir")
|
|
|
|
reportError("input language must be '', 'IR' or 'MIR'");
|
2017-06-06 22:06:57 +02:00
|
|
|
|
2012-11-30 22:42:47 +01:00
|
|
|
// Compile the module TimeCompilations times to give better compile time
|
|
|
|
// metrics.
|
|
|
|
for (unsigned I = TimeCompilations; I; --I)
|
|
|
|
if (int RetVal = compileModule(argv, Context))
|
|
|
|
return RetVal;
|
2017-01-26 01:39:51 +01:00
|
|
|
|
2019-06-14 18:20:51 +02:00
|
|
|
if (RemarksFile)
|
|
|
|
RemarksFile->keep();
|
2012-11-30 22:42:47 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-07-16 04:24:15 +02:00
|
|
|
static bool addPass(PassManagerBase &PM, const char *argv0,
|
|
|
|
StringRef PassName, TargetPassConfig &TPC) {
|
2017-04-01 03:26:24 +02:00
|
|
|
if (PassName == "none")
|
2016-07-16 04:24:59 +02:00
|
|
|
return false;
|
|
|
|
|
2017-04-01 03:26:24 +02:00
|
|
|
const PassRegistry *PR = PassRegistry::getPassRegistry();
|
|
|
|
const PassInfo *PI = PR->getPassInfo(PassName);
|
|
|
|
if (!PI) {
|
2018-06-23 18:51:10 +02:00
|
|
|
WithColor::error(errs(), argv0)
|
|
|
|
<< "run-pass " << PassName << " is not registered.\n";
|
2017-04-01 03:26:24 +02:00
|
|
|
return true;
|
|
|
|
}
|
2016-07-16 04:24:15 +02:00
|
|
|
|
|
|
|
Pass *P;
|
2017-05-18 19:21:13 +02:00
|
|
|
if (PI->getNormalCtor())
|
2016-07-16 04:24:15 +02:00
|
|
|
P = PI->getNormalCtor()();
|
|
|
|
else {
|
2018-06-23 18:51:10 +02:00
|
|
|
WithColor::error(errs(), argv0)
|
|
|
|
<< "cannot create pass: " << PI->getPassName() << "\n";
|
2016-07-16 04:24:15 +02:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
std::string Banner = std::string("After ") + std::string(P->getPassName());
|
2020-04-08 22:43:46 +02:00
|
|
|
TPC.addMachinePrePasses();
|
2016-07-16 04:24:15 +02:00
|
|
|
PM.add(P);
|
2020-04-08 22:43:46 +02:00
|
|
|
TPC.addMachinePostPasses(Banner);
|
2016-07-16 04:24:15 +02:00
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2012-11-30 22:42:47 +01:00
|
|
|
static int compileModule(char **argv, LLVMContext &Context) {
|
2007-05-06 06:55:19 +02:00
|
|
|
// Load the module to be compiled...
|
2009-09-02 21:35:19 +02:00
|
|
|
SMDiagnostic Err;
|
2014-03-06 06:51:42 +01:00
|
|
|
std::unique_ptr<Module> M;
|
2015-06-15 22:30:22 +02:00
|
|
|
std::unique_ptr<MIRParser> MIR;
|
2012-06-27 18:23:48 +02:00
|
|
|
Triple TheTriple;
|
2020-03-04 00:47:43 +01:00
|
|
|
std::string CPUStr = codegen::getCPUStr(),
|
|
|
|
FeaturesStr = codegen::getFeaturesStr();
|
2019-12-06 19:36:34 +01:00
|
|
|
|
|
|
|
// Set attributes on functions as loaded from MIR from command line arguments.
|
|
|
|
auto setMIRFunctionAttributes = [&CPUStr, &FeaturesStr](Function &F) {
|
2020-03-04 00:47:43 +01:00
|
|
|
codegen::setFunctionAttributes(CPUStr, FeaturesStr, F);
|
2019-12-06 19:36:34 +01:00
|
|
|
};
|
2012-06-27 18:23:48 +02:00
|
|
|
|
2020-03-04 00:47:43 +01:00
|
|
|
auto MAttrs = codegen::getMAttrs();
|
|
|
|
bool SkipModule = codegen::getMCPU() == "help" ||
|
2012-06-27 18:23:48 +02:00
|
|
|
(!MAttrs.empty() && MAttrs.front() == "help");
|
|
|
|
|
2011-11-16 09:38:26 +01:00
|
|
|
CodeGenOpt::Level OLvl = CodeGenOpt::Default;
|
|
|
|
switch (OptLevel) {
|
|
|
|
default:
|
2018-06-23 18:51:10 +02:00
|
|
|
WithColor::error(errs(), argv[0]) << "invalid optimization level.\n";
|
2011-11-16 09:38:26 +01:00
|
|
|
return 1;
|
|
|
|
case ' ': break;
|
|
|
|
case '0': OLvl = CodeGenOpt::None; break;
|
|
|
|
case '1': OLvl = CodeGenOpt::Less; break;
|
|
|
|
case '2': OLvl = CodeGenOpt::Default; break;
|
|
|
|
case '3': OLvl = CodeGenOpt::Aggressive; break;
|
|
|
|
}
|
|
|
|
|
Add -fbinutils-version= to gate ELF features on the specified binutils version
There are two use cases.
Assembler
We have accrued some code gated on MCAsmInfo::useIntegratedAssembler(). Some
features are supported by latest GNU as, but we have to use
MCAsmInfo::useIntegratedAs() because the newer versions have not been widely
adopted (e.g. SHF_LINK_ORDER 'o' and 'unique' linkage in 2.35, --compress-debug-sections= in 2.26).
Linker
We want to use features supported only by LLD or very new GNU ld, or don't want
to work around older GNU ld. We currently can't represent that "we don't care
about old GNU ld". You can find such workarounds in a few other places, e.g.
Mips/MipsAsmprinter.cpp PowerPC/PPCTOCRegDeps.cpp X86/X86MCInstrLower.cpp
AArch64 TLS workaround for R_AARCH64_TLSLD_MOVW_DTPREL_* (PR ld/18276),
R_AARCH64_TLSLE_LDST8_TPREL_LO12 (https://bugs.llvm.org/show_bug.cgi?id=36727 https://sourceware.org/bugzilla/show_bug.cgi?id=22969)
Mixed SHF_LINK_ORDER and non-SHF_LINK_ORDER components (supported by LLD in D84001;
GNU ld feature request https://sourceware.org/bugzilla/show_bug.cgi?id=16833 may take a while before available).
This feature allows to garbage collect some unused sections (e.g. fragmented .gcc_except_table).
This patch adds `-fbinutils-version=` to clang and `-binutils-version` to llc.
It changes one codegen place in SHF_MERGE to demonstrate its usage.
`-fbinutils-version=2.35` means the produced object file does not care about GNU
ld<2.35 compatibility. When `-fno-integrated-as` is specified, the produced
assembly can be consumed by GNU as>=2.35, but older versions may not work.
`-fbinutils-version=none` means that we can use all ELF features, regardless of
GNU as/ld support.
Both clang and llc need `parseBinutilsVersion`. Such command line parsing is
usually implemented in `llvm/lib/CodeGen/CommandFlags.cpp` (LLVMCodeGen),
however, ClangCodeGen does not depend on LLVMCodeGen. So I add
`parseBinutilsVersion` to `llvm/lib/Target/TargetMachine.cpp` (LLVMTarget).
Differential Revision: https://reviews.llvm.org/D85474
2021-01-26 21:28:23 +01:00
|
|
|
// Parse 'none' or '$major.$minor'. Disallow -binutils-version=0 because we
|
|
|
|
// use that to indicate the MC default.
|
|
|
|
if (!BinutilsVersion.empty() && BinutilsVersion != "none") {
|
|
|
|
StringRef V = BinutilsVersion.getValue();
|
|
|
|
unsigned Num;
|
|
|
|
if (V.consumeInteger(10, Num) || Num == 0 ||
|
|
|
|
!(V.empty() ||
|
|
|
|
(V.consume_front(".") && !V.consumeInteger(10, Num) && V.empty()))) {
|
|
|
|
WithColor::error(errs(), argv[0])
|
|
|
|
<< "invalid -binutils-version, accepting 'none' or major.minor\n";
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
2020-10-02 20:43:17 +02:00
|
|
|
TargetOptions Options;
|
|
|
|
auto InitializeOptions = [&](const Triple &TheTriple) {
|
2020-10-14 17:55:55 +02:00
|
|
|
Options = codegen::InitTargetOptionsFromCodeGenFlags(TheTriple);
|
Add -fbinutils-version= to gate ELF features on the specified binutils version
There are two use cases.
Assembler
We have accrued some code gated on MCAsmInfo::useIntegratedAssembler(). Some
features are supported by latest GNU as, but we have to use
MCAsmInfo::useIntegratedAs() because the newer versions have not been widely
adopted (e.g. SHF_LINK_ORDER 'o' and 'unique' linkage in 2.35, --compress-debug-sections= in 2.26).
Linker
We want to use features supported only by LLD or very new GNU ld, or don't want
to work around older GNU ld. We currently can't represent that "we don't care
about old GNU ld". You can find such workarounds in a few other places, e.g.
Mips/MipsAsmprinter.cpp PowerPC/PPCTOCRegDeps.cpp X86/X86MCInstrLower.cpp
AArch64 TLS workaround for R_AARCH64_TLSLD_MOVW_DTPREL_* (PR ld/18276),
R_AARCH64_TLSLE_LDST8_TPREL_LO12 (https://bugs.llvm.org/show_bug.cgi?id=36727 https://sourceware.org/bugzilla/show_bug.cgi?id=22969)
Mixed SHF_LINK_ORDER and non-SHF_LINK_ORDER components (supported by LLD in D84001;
GNU ld feature request https://sourceware.org/bugzilla/show_bug.cgi?id=16833 may take a while before available).
This feature allows to garbage collect some unused sections (e.g. fragmented .gcc_except_table).
This patch adds `-fbinutils-version=` to clang and `-binutils-version` to llc.
It changes one codegen place in SHF_MERGE to demonstrate its usage.
`-fbinutils-version=2.35` means the produced object file does not care about GNU
ld<2.35 compatibility. When `-fno-integrated-as` is specified, the produced
assembly can be consumed by GNU as>=2.35, but older versions may not work.
`-fbinutils-version=none` means that we can use all ELF features, regardless of
GNU as/ld support.
Both clang and llc need `parseBinutilsVersion`. Such command line parsing is
usually implemented in `llvm/lib/CodeGen/CommandFlags.cpp` (LLVMCodeGen),
however, ClangCodeGen does not depend on LLVMCodeGen. So I add
`parseBinutilsVersion` to `llvm/lib/Target/TargetMachine.cpp` (LLVMTarget).
Differential Revision: https://reviews.llvm.org/D85474
2021-01-26 21:28:23 +01:00
|
|
|
Options.BinutilsVersion =
|
|
|
|
TargetMachine::parseBinutilsVersion(BinutilsVersion);
|
2020-10-02 20:43:17 +02:00
|
|
|
Options.DisableIntegratedAS = NoIntegratedAssembler;
|
|
|
|
Options.MCOptions.ShowMCEncoding = ShowMCEncoding;
|
2021-07-13 02:44:02 +02:00
|
|
|
Options.MCOptions.MCUseDwarfDirectory = DwarfDirectory;
|
2020-10-02 20:43:17 +02:00
|
|
|
Options.MCOptions.AsmVerbose = AsmVerbose;
|
|
|
|
Options.MCOptions.PreserveAsmComments = PreserveComments;
|
|
|
|
Options.MCOptions.IASSearchPaths = IncludeDirs;
|
|
|
|
Options.MCOptions.SplitDwarfFile = SplitDwarfFile;
|
|
|
|
};
|
2014-05-21 01:59:50 +02:00
|
|
|
|
2020-03-04 00:47:43 +01:00
|
|
|
Optional<Reloc::Model> RM = codegen::getExplicitRelocModel();
|
[PowerPC][AIX] Make PIC the default relocation model for AIX
Summary:
The `llc` tool currently defaults to Static relocation model and generates non-relocatable code for 32-bit Power.
This is not desirable on AIX where we always generate Position Independent Code (PIC). This patch makes PIC the default relocation model for AIX.
Reviewers: daltenty, hubert.reinterpretcast, DiggerLin, Xiangling_L, sfertile
Reviewed By: hubert.reinterpretcast
Subscribers: mgorny, wuzish, nemanjai, hiraditya, kbarton, jsji, shchenz, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72479
2020-01-16 17:42:11 +01:00
|
|
|
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-14 21:59:45 +02:00
|
|
|
const Target *TheTarget = nullptr;
|
|
|
|
std::unique_ptr<TargetMachine> Target;
|
2015-05-07 01:49:24 +02:00
|
|
|
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-14 21:59:45 +02:00
|
|
|
// If user just wants to list available options, skip module loading
|
|
|
|
if (!SkipModule) {
|
|
|
|
auto SetDataLayout =
|
|
|
|
[&](StringRef DataLayoutTargetTriple) -> Optional<std::string> {
|
|
|
|
// If we are supposed to override the target triple, do so now.
|
|
|
|
std::string IRTargetTriple = DataLayoutTargetTriple.str();
|
|
|
|
if (!TargetTriple.empty())
|
|
|
|
IRTargetTriple = Triple::normalize(TargetTriple);
|
|
|
|
TheTriple = Triple(IRTargetTriple);
|
|
|
|
if (TheTriple.getTriple().empty())
|
|
|
|
TheTriple.setTriple(sys::getDefaultTargetTriple());
|
|
|
|
|
|
|
|
std::string Error;
|
|
|
|
TheTarget =
|
|
|
|
TargetRegistry::lookupTarget(codegen::getMArch(), TheTriple, Error);
|
|
|
|
if (!TheTarget) {
|
|
|
|
WithColor::error(errs(), argv[0]) << Error;
|
|
|
|
exit(1);
|
|
|
|
}
|
2014-05-06 18:29:50 +02:00
|
|
|
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-14 21:59:45 +02:00
|
|
|
// On AIX, setting the relocation model to anything other than PIC is
|
|
|
|
// considered a user error.
|
2021-01-27 00:33:37 +01:00
|
|
|
if (TheTriple.isOSAIX() && RM.hasValue() && *RM != Reloc::PIC_)
|
|
|
|
reportError("invalid relocation model, AIX only supports PIC",
|
|
|
|
InputFilename);
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-14 21:59:45 +02:00
|
|
|
|
2020-10-02 20:43:17 +02:00
|
|
|
InitializeOptions(TheTriple);
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-14 21:59:45 +02:00
|
|
|
Target = std::unique_ptr<TargetMachine>(TheTarget->createTargetMachine(
|
|
|
|
TheTriple.getTriple(), CPUStr, FeaturesStr, Options, RM,
|
|
|
|
codegen::getExplicitCodeModel(), OLvl));
|
|
|
|
assert(Target && "Could not allocate target machine!");
|
|
|
|
|
|
|
|
return Target->createDataLayout().getStringRepresentation();
|
|
|
|
};
|
|
|
|
if (InputLanguage == "mir" ||
|
|
|
|
(InputLanguage == "" && StringRef(InputFilename).endswith(".mir"))) {
|
|
|
|
MIR = createMIRParserFromFile(InputFilename, Err, Context,
|
|
|
|
setMIRFunctionAttributes);
|
|
|
|
if (MIR)
|
|
|
|
M = MIR->parseIRModule(SetDataLayout);
|
|
|
|
} else {
|
|
|
|
M = parseIRFile(InputFilename, Err, Context, SetDataLayout);
|
|
|
|
}
|
|
|
|
if (!M) {
|
|
|
|
Err.print(argv[0], WithColor::error(errs(), argv[0]));
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
if (!TargetTriple.empty())
|
|
|
|
M->setTargetTriple(Triple::normalize(TargetTriple));
|
|
|
|
} else {
|
|
|
|
TheTriple = Triple(Triple::normalize(TargetTriple));
|
|
|
|
if (TheTriple.getTriple().empty())
|
|
|
|
TheTriple.setTriple(sys::getDefaultTargetTriple());
|
|
|
|
|
|
|
|
// Get the target specific parser.
|
|
|
|
std::string Error;
|
|
|
|
TheTarget =
|
|
|
|
TargetRegistry::lookupTarget(codegen::getMArch(), TheTriple, Error);
|
|
|
|
if (!TheTarget) {
|
|
|
|
WithColor::error(errs(), argv[0]) << Error;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
// On AIX, setting the relocation model to anything other than PIC is
|
|
|
|
// considered a user error.
|
|
|
|
if (TheTriple.isOSAIX() && RM.hasValue() && *RM != Reloc::PIC_) {
|
|
|
|
WithColor::error(errs(), argv[0])
|
|
|
|
<< "invalid relocation model, AIX only supports PIC.\n";
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2020-10-02 20:43:17 +02:00
|
|
|
InitializeOptions(TheTriple);
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-14 21:59:45 +02:00
|
|
|
Target = std::unique_ptr<TargetMachine>(TheTarget->createTargetMachine(
|
|
|
|
TheTriple.getTriple(), CPUStr, FeaturesStr, Options, RM,
|
|
|
|
codegen::getExplicitCodeModel(), OLvl));
|
|
|
|
assert(Target && "Could not allocate target machine!");
|
|
|
|
|
|
|
|
// If we don't have a module then just exit now. We do this down
|
|
|
|
// here since the CPU/Feature help is underneath the target machine
|
|
|
|
// creation.
|
2014-05-06 18:29:50 +02:00
|
|
|
return 0;
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-14 21:59:45 +02:00
|
|
|
}
|
2014-05-06 18:29:50 +02:00
|
|
|
|
2014-12-11 08:04:52 +01:00
|
|
|
assert(M && "Should have exited if we didn't have a module!");
|
2020-03-04 00:47:43 +01:00
|
|
|
if (codegen::getFloatABIForCalls() != FloatABI::Default)
|
|
|
|
Options.FloatABIType = codegen::getFloatABIForCalls();
|
2011-12-02 23:16:29 +01:00
|
|
|
|
2012-07-19 02:11:45 +02:00
|
|
|
// Figure out where we are going to send the output.
|
2017-09-23 03:03:17 +02:00
|
|
|
std::unique_ptr<ToolOutputFile> Out =
|
2014-12-12 08:52:00 +01:00
|
|
|
GetOutputStream(TheTarget->getName(), TheTriple.getOS(), argv[0]);
|
2010-08-20 03:07:01 +02:00
|
|
|
if (!Out) return 1;
|
2009-01-16 07:53:46 +01:00
|
|
|
|
2018-05-21 22:16:41 +02:00
|
|
|
std::unique_ptr<ToolOutputFile> DwoOut;
|
|
|
|
if (!SplitDwarfOutputFile.empty()) {
|
|
|
|
std::error_code EC;
|
2019-08-15 17:54:37 +02:00
|
|
|
DwoOut = std::make_unique<ToolOutputFile>(SplitDwarfOutputFile, EC,
|
2019-08-05 07:43:48 +02:00
|
|
|
sys::fs::OF_None);
|
2021-01-27 00:33:37 +01:00
|
|
|
if (EC)
|
|
|
|
reportError(EC.message(), SplitDwarfOutputFile);
|
2018-05-21 22:16:41 +02:00
|
|
|
}
|
|
|
|
|
2010-05-11 21:57:55 +02:00
|
|
|
// Build up all of the passes that we want to do to the module.
|
2015-02-13 11:01:29 +01:00
|
|
|
legacy::PassManager PM;
|
2010-05-11 21:57:55 +02:00
|
|
|
|
2012-08-03 23:26:18 +02:00
|
|
|
// Add an appropriate TargetLibraryInfo pass for the module's triple.
|
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass
manager to support the actual uses of it. =]
When I ported instcombine to the new pass manager I discover that it
didn't work because TLI wasn't available in the right places. This is
a somewhat surprising and/or subtle aspect of the new pass manager
design that came up before but I think is useful to be reminded of:
While the new pass manager *allows* a function pass to query a module
analysis, it requires that the module analysis is already run and cached
prior to the function pass manager starting up, possibly with
a 'require<foo>' style utility in the pass pipeline. This is an
intentional hurdle because using a module analysis from a function pass
*requires* that the module analysis is run prior to entering the
function pass manager. Otherwise the other functions in the module could
be in who-knows-what state, etc.
A somewhat surprising consequence of this design decision (at least to
me) is that you have to design a function pass that leverages
a module analysis to do so as an optional feature. Even if that means
your function pass does no work in the absence of the module analysis,
you have to handle that possibility and remain conservatively correct.
This is a natural consequence of things being able to invalidate the
module analysis and us being unable to re-run it. And it's a generally
good thing because it lets us reorder passes arbitrarily without
breaking correctness, etc.
This ends up causing problems in one case. What if we have a module
analysis that is *definitionally* impossible to invalidate. In the
places this might come up, the analysis is usually also definitionally
trivial to run even while other transformation passes run on the module,
regardless of the state of anything. And so, it follows that it is
natural to have a hard requirement on such analyses from a function
pass.
It turns out, that TargetLibraryInfo is just such an analysis, and
InstCombine has a hard requirement on it.
The approach I've taken here is to produce an analysis that models this
flexibility by making it both a module and a function analysis. This
exposes the fact that it is in fact safe to compute at any point. We can
even make it a valid CGSCC analysis at some point if that is useful.
However, we don't want to have a copy of the actual target library info
state for each function! This state is specific to the triple. The
somewhat direct and blunt approach here is to turn TLI into a pimpl,
with the state and mutators in the implementation class and the query
routines primarily in the wrapper. Then the analysis can lazily
construct and cache the implementations, keyed on the triple, and
on-demand produce wrappers of them for each function.
One minor annoyance is that we will end up with a wrapper for each
function in the module. While this is a bit wasteful (one pointer per
function) it seems tolerable. And it has the advantage of ensuring that
we pay the absolute minimum synchronization cost to access this
information should we end up with a nice parallel function pass manager
in the future. We could look into trying to mark when analysis results
are especially cheap to recompute and more eagerly GC-ing the cached
results, or we could look at supporting a variant of analyses whose
results are specifically *not* cached and expected to just be used and
discarded by the consumer. Either way, these seem like incremental
enhancements that should happen when we start profiling the memory and
CPU usage of the new pass manager and not before.
The other minor annoyance is that if we end up using the TLI in both
a module pass and a function pass, those will be produced by two
separate analyses, and thus will point to separate copies of the
implementation state. While a minor issue, I dislike this and would like
to find a way to cleanly allow a single analysis instance to be used
across multiple IR unit managers. But I don't have a good solution to
this today, and I don't want to hold up all of the work waiting to come
up with one. This too seems like a reasonable thing to incrementally
improve later.
llvm-svn: 226981
2015-01-24 03:06:09 +01:00
|
|
|
TargetLibraryInfoImpl TLII(Triple(M->getTargetTriple()));
|
2015-01-15 11:41:28 +01:00
|
|
|
|
|
|
|
// The -disable-simplify-libcalls flag actually disables all builtin optzns.
|
2012-08-08 22:31:37 +02:00
|
|
|
if (DisableSimplifyLibCalls)
|
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass
manager to support the actual uses of it. =]
When I ported instcombine to the new pass manager I discover that it
didn't work because TLI wasn't available in the right places. This is
a somewhat surprising and/or subtle aspect of the new pass manager
design that came up before but I think is useful to be reminded of:
While the new pass manager *allows* a function pass to query a module
analysis, it requires that the module analysis is already run and cached
prior to the function pass manager starting up, possibly with
a 'require<foo>' style utility in the pass pipeline. This is an
intentional hurdle because using a module analysis from a function pass
*requires* that the module analysis is run prior to entering the
function pass manager. Otherwise the other functions in the module could
be in who-knows-what state, etc.
A somewhat surprising consequence of this design decision (at least to
me) is that you have to design a function pass that leverages
a module analysis to do so as an optional feature. Even if that means
your function pass does no work in the absence of the module analysis,
you have to handle that possibility and remain conservatively correct.
This is a natural consequence of things being able to invalidate the
module analysis and us being unable to re-run it. And it's a generally
good thing because it lets us reorder passes arbitrarily without
breaking correctness, etc.
This ends up causing problems in one case. What if we have a module
analysis that is *definitionally* impossible to invalidate. In the
places this might come up, the analysis is usually also definitionally
trivial to run even while other transformation passes run on the module,
regardless of the state of anything. And so, it follows that it is
natural to have a hard requirement on such analyses from a function
pass.
It turns out, that TargetLibraryInfo is just such an analysis, and
InstCombine has a hard requirement on it.
The approach I've taken here is to produce an analysis that models this
flexibility by making it both a module and a function analysis. This
exposes the fact that it is in fact safe to compute at any point. We can
even make it a valid CGSCC analysis at some point if that is useful.
However, we don't want to have a copy of the actual target library info
state for each function! This state is specific to the triple. The
somewhat direct and blunt approach here is to turn TLI into a pimpl,
with the state and mutators in the implementation class and the query
routines primarily in the wrapper. Then the analysis can lazily
construct and cache the implementations, keyed on the triple, and
on-demand produce wrappers of them for each function.
One minor annoyance is that we will end up with a wrapper for each
function in the module. While this is a bit wasteful (one pointer per
function) it seems tolerable. And it has the advantage of ensuring that
we pay the absolute minimum synchronization cost to access this
information should we end up with a nice parallel function pass manager
in the future. We could look into trying to mark when analysis results
are especially cheap to recompute and more eagerly GC-ing the cached
results, or we could look at supporting a variant of analyses whose
results are specifically *not* cached and expected to just be used and
discarded by the consumer. Either way, these seem like incremental
enhancements that should happen when we start profiling the memory and
CPU usage of the new pass manager and not before.
The other minor annoyance is that if we end up using the TLI in both
a module pass and a function pass, those will be produced by two
separate analyses, and thus will point to separate copies of the
implementation state. While a minor issue, I dislike this and would like
to find a way to cleanly allow a single analysis instance to be used
across multiple IR unit managers. But I don't have a good solution to
this today, and I don't want to hold up all of the work waiting to come
up with one. This too seems like a reasonable thing to incrementally
improve later.
llvm-svn: 226981
2015-01-24 03:06:09 +01:00
|
|
|
TLII.disableAllFunctions();
|
|
|
|
PM.add(new TargetLibraryInfoWrapperPass(TLII));
|
2012-08-03 23:26:18 +02:00
|
|
|
|
2018-01-30 23:32:39 +01:00
|
|
|
// Verify module immediately to catch problems before doInitialization() is
|
|
|
|
// called on any passes.
|
2021-01-27 00:33:37 +01:00
|
|
|
if (!NoVerify && verifyModule(*M, &errs()))
|
|
|
|
reportError("input module cannot be verified", InputFilename);
|
2018-01-30 23:32:39 +01:00
|
|
|
|
2015-05-26 22:17:20 +02:00
|
|
|
// Override function attributes based on CPUStr, FeaturesStr, and command line
|
|
|
|
// flags.
|
2020-03-04 00:47:43 +01:00
|
|
|
codegen::setFunctionAttributes(CPUStr, FeaturesStr, *M);
|
2015-05-07 01:54:14 +02:00
|
|
|
|
2020-03-04 00:47:43 +01:00
|
|
|
if (mc::getExplicitRelaxAll() && codegen::getFileType() != CGFT_ObjectFile)
|
2018-06-23 18:51:10 +02:00
|
|
|
WithColor::warning(errs(), argv[0])
|
|
|
|
<< ": warning: ignoring -mc-relax-all because filetype != obj";
|
2010-07-31 21:57:02 +02:00
|
|
|
|
2010-09-01 16:20:41 +02:00
|
|
|
{
|
2015-04-15 00:14:34 +02:00
|
|
|
raw_pwrite_stream *OS = &Out->os();
|
2015-12-04 22:56:46 +01:00
|
|
|
|
|
|
|
// Manually do the buffering rather than using buffer_ostream,
|
|
|
|
// so we can memcmp the contents in CompileTwice mode
|
|
|
|
SmallVector<char, 0> Buffer;
|
|
|
|
std::unique_ptr<raw_svector_ostream> BOS;
|
2020-03-04 00:47:43 +01:00
|
|
|
if ((codegen::getFileType() != CGFT_AssemblyFile &&
|
2015-12-04 22:56:46 +01:00
|
|
|
!Out->os().supportsSeeking()) ||
|
|
|
|
CompileTwice) {
|
2019-08-15 17:54:37 +02:00
|
|
|
BOS = std::make_unique<raw_svector_ostream>(Buffer);
|
2015-04-15 00:14:34 +02:00
|
|
|
OS = BOS.get();
|
|
|
|
}
|
|
|
|
|
2017-06-06 02:26:24 +02:00
|
|
|
const char *argv0 = argv[0];
|
2019-09-30 19:54:50 +02:00
|
|
|
LLVMTargetMachine &LLVMTM = static_cast<LLVMTargetMachine &>(*Target);
|
|
|
|
MachineModuleInfoWrapperPass *MMIWP =
|
|
|
|
new MachineModuleInfoWrapperPass(&LLVMTM);
|
2017-07-31 20:24:07 +02:00
|
|
|
|
|
|
|
// Construct a custom pass pipeline that starts after instruction
|
|
|
|
// selection.
|
|
|
|
if (!RunPassNames->empty()) {
|
|
|
|
if (!MIR) {
|
2018-06-23 18:51:10 +02:00
|
|
|
WithColor::warning(errs(), argv[0])
|
|
|
|
<< "run-pass is for .mir file only.\n";
|
2017-07-31 20:24:07 +02:00
|
|
|
return 1;
|
|
|
|
}
|
2017-10-13 00:57:28 +02:00
|
|
|
TargetPassConfig &TPC = *LLVMTM.createPassConfig(PM);
|
2017-07-31 20:24:07 +02:00
|
|
|
if (TPC.hasLimitedCodeGenPipeline()) {
|
2018-06-23 18:51:10 +02:00
|
|
|
WithColor::warning(errs(), argv[0])
|
|
|
|
<< "run-pass cannot be used with "
|
|
|
|
<< TPC.getLimitedCodeGenPipelineReason(" and ") << ".\n";
|
2017-07-31 20:24:07 +02:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2017-06-06 02:26:24 +02:00
|
|
|
TPC.setDisableVerify(NoVerify);
|
2016-07-16 04:24:15 +02:00
|
|
|
PM.add(&TPC);
|
2019-09-30 19:54:50 +02:00
|
|
|
PM.add(MMIWP);
|
2016-07-16 04:24:15 +02:00
|
|
|
TPC.printAndVerify("");
|
2017-07-31 20:24:07 +02:00
|
|
|
for (const std::string &RunPassName : *RunPassNames) {
|
|
|
|
if (addPass(PM, argv0, RunPassName, TPC))
|
2016-06-10 02:52:10 +02:00
|
|
|
return 1;
|
2016-05-10 03:32:44 +02:00
|
|
|
}
|
2017-06-06 02:26:24 +02:00
|
|
|
TPC.setInitialized();
|
2017-07-31 20:24:07 +02:00
|
|
|
PM.add(createPrintMIRPass(*OS));
|
2017-06-06 02:26:24 +02:00
|
|
|
PM.add(createFreeMachineFunctionPass());
|
2020-03-04 00:47:43 +01:00
|
|
|
} else if (Target->addPassesToEmitFile(
|
|
|
|
PM, *OS, DwoOut ? &DwoOut->os() : nullptr,
|
|
|
|
codegen::getFileType(), NoVerify, MMIWP)) {
|
2021-01-27 00:33:37 +01:00
|
|
|
reportError("target does not support generation of this file type");
|
2010-09-01 16:20:41 +02:00
|
|
|
}
|
|
|
|
|
2020-03-20 06:58:42 +01:00
|
|
|
const_cast<TargetLoweringObjectFile *>(LLVMTM.getObjFileLowering())
|
|
|
|
->Initialize(MMIWP->getMMI().getContext(), *Target);
|
2017-07-31 20:24:07 +02:00
|
|
|
if (MIR) {
|
2019-09-30 19:54:50 +02:00
|
|
|
assert(MMIWP && "Forgot to create MMIWP?");
|
|
|
|
if (MIR->parseMachineFunctions(*M, MMIWP->getMMI()))
|
2017-07-31 20:24:07 +02:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2011-04-05 20:54:36 +02:00
|
|
|
// Before executing passes, print the final values of the LLVM options.
|
|
|
|
cl::PrintOptionValues();
|
|
|
|
|
2015-12-04 22:56:46 +01:00
|
|
|
// If requested, run the pass manager over the same module again,
|
|
|
|
// to catch any bugs due to persistent state in the passes. Note that
|
|
|
|
// opt has the same functionality, so it may be worth abstracting this out
|
|
|
|
// in the future.
|
|
|
|
SmallVector<char, 0> CompileTwiceBuffer;
|
|
|
|
if (CompileTwice) {
|
2018-02-14 20:50:40 +01:00
|
|
|
std::unique_ptr<Module> M2(llvm::CloneModule(*M));
|
2015-12-04 22:56:46 +01:00
|
|
|
PM.run(*M2);
|
|
|
|
CompileTwiceBuffer = Buffer;
|
|
|
|
Buffer.clear();
|
|
|
|
}
|
|
|
|
|
2014-12-11 08:04:52 +01:00
|
|
|
PM.run(*M);
|
2015-12-04 22:56:46 +01:00
|
|
|
|
2017-09-15 22:10:09 +02:00
|
|
|
auto HasError =
|
|
|
|
((const LLCDiagnosticHandler *)(Context.getDiagHandlerPtr()))->HasError;
|
|
|
|
if (*HasError)
|
2016-06-23 11:49:56 +02:00
|
|
|
return 1;
|
2016-05-16 16:28:02 +02:00
|
|
|
|
2015-12-04 22:56:46 +01:00
|
|
|
// Compare the two outputs and make sure they're the same
|
|
|
|
if (CompileTwice) {
|
|
|
|
if (Buffer.size() != CompileTwiceBuffer.size() ||
|
|
|
|
(memcmp(Buffer.data(), CompileTwiceBuffer.data(), Buffer.size()) !=
|
|
|
|
0)) {
|
|
|
|
errs()
|
|
|
|
<< "Running the pass manager twice changed the output.\n"
|
|
|
|
"Writing the result of the second run to the specified output\n"
|
|
|
|
"To generate the one-run comparison binary, just run without\n"
|
|
|
|
"the compile-twice option\n";
|
|
|
|
Out->os() << Buffer;
|
|
|
|
Out->keep();
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (BOS) {
|
|
|
|
Out->os() << Buffer;
|
|
|
|
}
|
2010-09-01 16:20:41 +02:00
|
|
|
}
|
2010-05-11 21:57:55 +02:00
|
|
|
|
2010-08-20 03:07:01 +02:00
|
|
|
// Declare success.
|
|
|
|
Out->keep();
|
2018-05-21 22:16:41 +02:00
|
|
|
if (DwoOut)
|
|
|
|
DwoOut->keep();
|
2001-10-18 03:31:22 +02:00
|
|
|
|
2007-05-06 06:55:19 +02:00
|
|
|
return 0;
|
2001-10-15 01:29:28 +02:00
|
|
|
}
|