maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/CodeGen/CommandFlags.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

716 lines
28 KiB
C++
Raw Normal View History

Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
//===-- CommandFlags.cpp - Command Line Flags Interface ---------*- C++ -*-===//
//
// 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
//
//===----------------------------------------------------------------------===//
//
// This file contains codegen-specific flags that are shared between different
// command line tools. The tools "llc" and "opt" both use this file to prevent
// flag duplication.
//
//===----------------------------------------------------------------------===//
#include "llvm/CodeGen/CommandFlags.h"
CommandFlags.h - remove unnecessary includes. NFC. Replace with forward declarations and move necessary includes down to source files. Exposes an implicit dependency on TargetMachine.h in llvm-opt-fuzzer.cpp
2020-05-20 00:12:32 +08:00
#include "llvm/IR/Module.h"
#include "llvm/MC/SubtargetFeature.h"
#include "llvm/Support/CommandLine.h"
#include "llvm/Support/Host.h"
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
using namespace llvm;
#define CGOPT(TY, NAME) \
static cl::opt<TY> *NAME##View; \
TY codegen::get##NAME() { \
assert(NAME##View && "RegisterCodeGenFlags not created."); \
return *NAME##View; \
}
#define CGLIST(TY, NAME) \
static cl::list<TY> *NAME##View; \
std::vector<TY> codegen::get##NAME() { \
assert(NAME##View && "RegisterCodeGenFlags not created."); \
return *NAME##View; \
}
#define CGOPT_EXP(TY, NAME) \
CGOPT(TY, NAME) \
Optional<TY> codegen::getExplicit##NAME() { \
if (NAME##View->getNumOccurrences()) { \
TY res = *NAME##View; \
return res; \
} \
return None; \
}
CGOPT(std::string, MArch)
CGOPT(std::string, MCPU)
CGLIST(std::string, MAttrs)
CGOPT_EXP(Reloc::Model, RelocModel)
CGOPT(ThreadModel::Model, ThreadModel)
CGOPT_EXP(CodeModel::Model, CodeModel)
CGOPT(ExceptionHandling, ExceptionModel)
CGOPT_EXP(CodeGenFileType, FileType)
CGOPT(FramePointer::FP, FramePointerUsage)
CGOPT(bool, EnableUnsafeFPMath)
CGOPT(bool, EnableNoInfsFPMath)
CGOPT(bool, EnableNoNaNsFPMath)
CGOPT(bool, EnableNoSignedZerosFPMath)
CGOPT(bool, EnableNoTrappingFPMath)
[AIX] Add mabi=vec-extabi options to enable the AIX extended and default vector ABIs. Added support for the options mabi=vec-extabi and mabi=vec-default which are analogous to qvecnvol and qnovecnvol when using XL on AIX. The extended Altivec ABI on AIX is enabled using mabi=vec-extabi in clang and vec-extabi in llc. Reviewed By: Xiangling_L, DiggerLin Differential Revision: https://reviews.llvm.org/D89684
2020-11-25 07:11:46 +08:00
CGOPT(bool, EnableAIXExtendedAltivecABI)
Fix denormal-fp-math flag and attribute interaction Make these behave the same way unsafe-fp-math and co. The command line flag should add the attribute to functions that do not already have it, and leave existing attributes. The attribute is the actual implementation, but the flag is useful in some testing situations. AMDGPU has a variety of tests with denormals enabled/disabled that would require a painful level of test duplication without a flag. This doesn't expose setting the separate input/output modes, or add a flag for the f32 version yet. Tests will be included in future patch.
2020-03-12 05:12:20 +08:00
CGOPT(DenormalMode::DenormalModeKind, DenormalFPMath)
CodeGen: Add -denormal-fp-math-f32 flag Make the set of FP related attributes and command flags closer.
2019-12-04 17:04:14 +08:00
CGOPT(DenormalMode::DenormalModeKind, DenormalFP32Math)
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
CGOPT(bool, EnableHonorSignDependentRoundingFPMath)
CGOPT(FloatABI::ABIType, FloatABIForCalls)
CGOPT(FPOpFusion::FPOpFusionMode, FuseFPOps)
CGOPT(bool, DontPlaceZerosInBSS)
CGOPT(bool, EnableGuaranteedTailCallOpt)
CGOPT(bool, DisableTailCalls)
CGOPT(bool, StackSymbolOrdering)
CGOPT(unsigned, OverrideStackAlignment)
CGOPT(bool, StackRealign)
CGOPT(std::string, TrapFuncName)
CGOPT(bool, UseCtors)
CGOPT(bool, RelaxELFRelocations)
CGOPT_EXP(bool, DataSections)
CGOPT_EXP(bool, FunctionSections)
[AIX] add new option -mignore-xcoff-visibility SUMMARY: In IBM compiler xlclang , there is an option -fnovisibility which suppresses visibility. For more details see: https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_visibility.html. We need to add the option -mignore-xcoff-visibility for compatibility with the IBM AIX OS (as the option is enabled by default in AIX). With this option llvm does not emit any visibility attribute to ASM or XCOFF object file. The option only work on the AIX OS, for other non-AIX OS using the option will report an unsupported options error. In AIX OS: 1.1 the option -mignore-xcoff-visibility is enabled by default , if there is not -fvisibility=* and -mignore-xcoff-visibility explicitly in the clang command . 1.2 if there is -fvisibility=* explicitly but not -mignore-xcoff-visibility explicitly in the clang command. it will generate visibility attributes. 1.3 if there are both -fvisibility=* and -mignore-xcoff-visibility explicitly in the clang command. The option "-mignore-xcoff-visibility" wins , it do not emit the visibility attribute. The option -mignore-xcoff-visibility has no effect on visibility attribute when compile with -emit-llvm option to generated LLVM IR. Reviewer: daltenty,Jason Liu Differential Revision: https://reviews.llvm.org/D87451
2020-10-08 21:34:58 +08:00
CGOPT(bool, IgnoreXCOFFVisibility)
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
CGOPT(std::string, BBSections)
[X86] Support customizing stack protector guard Reviewed By: nickdesaulniers, MaskRay Differential Revision: https://reviews.llvm.org/D88631
2020-10-22 09:46:42 +08:00
CGOPT(std::string, StackProtectorGuard)
CGOPT(unsigned, StackProtectorGuardOffset)
CGOPT(std::string, StackProtectorGuardReg)
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
CGOPT(unsigned, TLSSize)
CGOPT(bool, EmulatedTLS)
CGOPT(bool, UniqueSectionNames)
Options for Basic Block Sections, enabled in D68063 and D73674. This patch adds clang options: -fbasic-block-sections={all,<filename>,labels,none} and -funique-basic-block-section-names. LLVM Support for basic block sections is already enabled. + -fbasic-block-sections={all, <file>, labels, none} : Enables/Disables basic block sections for all or a subset of basic blocks. "labels" only enables basic block symbols. + -funique-basic-block-section-names: Enables unique section names for basic block sections, disabled by default. Differential Revision: https://reviews.llvm.org/D68049
2020-06-02 14:17:29 +08:00
CGOPT(bool, UniqueBasicBlockSectionNames)
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
CGOPT(EABI, EABIVersion)
CGOPT(DebuggerKind, DebuggerTuningOpt)
CGOPT(bool, EnableStackSizeSection)
CGOPT(bool, EnableAddrsig)
CGOPT(bool, EmitCallSiteInfo)
[llvm][CodeGen] Machine Function Splitter We introduce a codegen optimization pass which splits functions into hot and cold parts. This pass leverages the basic block sections feature recently introduced in LLVM from the Propeller project. The pass targets functions with profile coverage, identifies cold blocks and moves them to a separate section. The linker groups all cold blocks across functions together, decreasing fragmentation and improving icache and itlb utilization. We evaluated the Machine Function Splitter pass on clang bootstrap and SPECInt 2017. For clang bootstrap we observe a mean 2.33% runtime improvement with a ~32% reduction in itlb and stlb misses. Additionally, L1 icache misses reduced by 9.5% while L2 instruction misses reduced by 20%. For SPECInt we report the change in IntRate the C/C++ benchmarks. All benchmarks apart from mcf and x264 improve, on average by 0.6% with the max for deepsjeng at 1.6%. Benchmark % Change 500.perlbench_r 0.78 502.gcc_r 0.82 505.mcf_r -0.30 520.omnetpp_r 0.18 523.xalancbmk_r 0.37 525.x264_r -0.46 531.deepsjeng_r 1.61 541.leela_r 0.83 557.xz_r 0.15 Differential Revision: https://reviews.llvm.org/D85368
2020-08-06 06:34:31 +08:00
CGOPT(bool, EnableMachineFunctionSplitter)
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
CGOPT(bool, EnableDebugEntryValues)
[CSSPGO] Pseudo probes for function calls. An indirect call site needs to be probed for its potential call targets. With CSSPGO a direct call also needs a probe so that a calling context can be represented by a stack of callsite probes. Unlike pseudo probes for basic blocks that are in form of standalone intrinsic call instructions, pseudo probes for callsites have to be attached to the call instruction, thus a separate instruction would not work. One possible way of attaching a probe to a call instruction is to use a special metadata that carries information about the probe. The special metadata will have to make its way through the optimization pipeline down to object emission. This requires additional efforts to maintain the metadata in various places. Given that the `!dbg` metadata is a first-class metadata and has all essential support in place , leveraging the `!dbg` metadata as a channel to encode pseudo probe information is probably the easiest solution. With the requirement of not inflating `!dbg` metadata that is allocated for almost every instruction, we found that the 32-bit DWARF discriminator field which mainly serves AutoFDO can be reused for pseudo probes. DWARF discriminators distinguish identical source locations between instructions and with pseudo probes such support is not required. In this change we are using the discriminator field to encode the ID and type of a callsite probe and the encoded value will be unpacked and consumed right before object emission. When a callsite is inlined, the callsite discriminator field will go with the inlined instructions. The `!dbg` metadata of an inlined instruction is in form of a scope stack. The top of the stack is the instruction's original `!dbg` metadata and the bottom of the stack is for the original callsite of the top-level inliner. Except for the top of the stack, all other elements of the stack actually refer to the nested inlined callsites whose discriminator field (which actually represents a calliste probe) can be used together to represent the inline context of an inlined PseudoProbeInst or CallInst. To avoid collision with the baseline AutoFDO in various places that handles dwarf discriminators where a check against the `-pseudo-probe-for-profiling` switch is not available, a special encoding scheme is used to tell apart a pseudo probe discriminator from a regular discriminator. For the regular discriminator, if all lowest 3 bits are non-zero, it means the discriminator is basically empty and all higher 29 bits can be reversed for pseudo probe use. Callsite pseudo probes are inserted in `SampleProfileProbePass` and a target-independent MIR pass `PseudoProbeInserter` is added to unpack the probe ID/type from `!dbg`. Note that with this work the switch -debug-info-for-profiling will not work with -pseudo-probe-for-profiling anymore. They cannot be used at the same time. Reviewed By: wmi Differential Revision: https://reviews.llvm.org/D91756
2020-12-02 13:44:06 +08:00
CGOPT(bool, PseudoProbeForProfiling)
[LiveDebugValues] Add switches for using instr-ref variable locations This patch adds the -Xclang option "-fexperimental-debug-variable-locations" and same LLVM CodeGen option, to pick which variable location tracking solution to use. Right now all the switch does is pick which LiveDebugValues implementation to use, the normal VarLoc one or the instruction referencing one in rGae6f78824031. Over time, the aim is to add fragments of support in aid of the value-tracking RFC: http://lists.llvm.org/pipermail/llvm-dev/2020-February/139440.html also controlled by this command line switch. That will slowly move variable locations to be defined by an instruction calculating a value, and a DBG_INSTR_REF instruction referring to that value. Thus, this is going to grow into a "use the new kind of variable locations" switch, rather than just "use the new LiveDebugValues implementation". Differential Revision: https://reviews.llvm.org/D83048
2020-08-25 21:23:14 +08:00
CGOPT(bool, ValueTrackingVariableLocations)
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
CGOPT(bool, ForceDwarfFrameSection)
[xray] Option to omit the function index Summary: Add a flag to omit the xray_fn_idx to cut size overhead and relocations roughly in half at the cost of reduced performance for single function patching. Minor additions to compiler-rt support per-function patching without the index. Reviewers: dberris, MaskRay, johnislarry Subscribers: hiraditya, arphaman, cfe-commits, #sanitizers, llvm-commits Tags: #clang, #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D81995
2020-06-17 08:36:11 +08:00
CGOPT(bool, XRayOmitFunctionIndex)
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
codegen::RegisterCodeGenFlags::RegisterCodeGenFlags() {
#define CGBINDOPT(NAME) \
do { \
NAME##View = std::addressof(NAME); \
} while (0)
static cl::opt<std::string> MArch(
"march", cl::desc("Architecture to generate code for (see --version)"));
CGBINDOPT(MArch);
static cl::opt<std::string> MCPU(
"mcpu", cl::desc("Target a specific cpu type (-mcpu=help for details)"),
cl::value_desc("cpu-name"), cl::init(""));
CGBINDOPT(MCPU);
static cl::list<std::string> MAttrs(
"mattr", cl::CommaSeparated,
cl::desc("Target specific attributes (-mattr=help for details)"),
cl::value_desc("a1,+a2,-a3,..."));
CGBINDOPT(MAttrs);
static cl::opt<Reloc::Model> RelocModel(
"relocation-model", cl::desc("Choose relocation model"),
cl::values(
clEnumValN(Reloc::Static, "static", "Non-relocatable code"),
clEnumValN(Reloc::PIC_, "pic",
"Fully relocatable, position independent code"),
clEnumValN(Reloc::DynamicNoPIC, "dynamic-no-pic",
"Relocatable external references, non-relocatable code"),
clEnumValN(
Reloc::ROPI, "ropi",
"Code and read-only data relocatable, accessed PC-relative"),
clEnumValN(
Reloc::RWPI, "rwpi",
"Read-write data relocatable, accessed relative to static base"),
clEnumValN(Reloc::ROPI_RWPI, "ropi-rwpi",
"Combination of ropi and rwpi")));
CGBINDOPT(RelocModel);
static cl::opt<ThreadModel::Model> ThreadModel(
"thread-model", cl::desc("Choose threading model"),
cl::init(ThreadModel::POSIX),
cl::values(
clEnumValN(ThreadModel::POSIX, "posix", "POSIX thread model"),
clEnumValN(ThreadModel::Single, "single", "Single thread model")));
CGBINDOPT(ThreadModel);
static cl::opt<CodeModel::Model> CodeModel(
"code-model", cl::desc("Choose code model"),
cl::values(clEnumValN(CodeModel::Tiny, "tiny", "Tiny code model"),
clEnumValN(CodeModel::Small, "small", "Small code model"),
clEnumValN(CodeModel::Kernel, "kernel", "Kernel code model"),
clEnumValN(CodeModel::Medium, "medium", "Medium code model"),
clEnumValN(CodeModel::Large, "large", "Large code model")));
CGBINDOPT(CodeModel);
static cl::opt<ExceptionHandling> ExceptionModel(
"exception-model", cl::desc("exception model"),
cl::init(ExceptionHandling::None),
cl::values(
clEnumValN(ExceptionHandling::None, "default",
"default exception handling model"),
clEnumValN(ExceptionHandling::DwarfCFI, "dwarf",
"DWARF-like CFI based exception handling"),
clEnumValN(ExceptionHandling::SjLj, "sjlj",
"SjLj exception handling"),
clEnumValN(ExceptionHandling::ARM, "arm", "ARM EHABI exceptions"),
clEnumValN(ExceptionHandling::WinEH, "wineh",
"Windows exception model"),
clEnumValN(ExceptionHandling::Wasm, "wasm",
"WebAssembly exception handling")));
CGBINDOPT(ExceptionModel);
static cl::opt<CodeGenFileType> FileType(
"filetype", cl::init(CGFT_AssemblyFile),
cl::desc(
"Choose a file type (not all types are supported by all targets):"),
cl::values(
clEnumValN(CGFT_AssemblyFile, "asm", "Emit an assembly ('.s') file"),
clEnumValN(CGFT_ObjectFile, "obj",
"Emit a native object ('.o') file"),
clEnumValN(CGFT_Null, "null",
"Emit nothing, for performance testing")));
CGBINDOPT(FileType);
static cl::opt<FramePointer::FP> FramePointerUsage(
"frame-pointer",
cl::desc("Specify frame pointer elimination optimization"),
cl::init(FramePointer::None),
cl::values(
clEnumValN(FramePointer::All, "all",
"Disable frame pointer elimination"),
clEnumValN(FramePointer::NonLeaf, "non-leaf",
"Disable frame pointer elimination for non-leaf frame"),
clEnumValN(FramePointer::None, "none",
"Enable frame pointer elimination")));
CGBINDOPT(FramePointerUsage);
static cl::opt<bool> EnableUnsafeFPMath(
"enable-unsafe-fp-math",
cl::desc("Enable optimizations that may decrease FP precision"),
cl::init(false));
CGBINDOPT(EnableUnsafeFPMath);
static cl::opt<bool> EnableNoInfsFPMath(
"enable-no-infs-fp-math",
cl::desc("Enable FP math optimizations that assume no +-Infs"),
cl::init(false));
CGBINDOPT(EnableNoInfsFPMath);
static cl::opt<bool> EnableNoNaNsFPMath(
"enable-no-nans-fp-math",
cl::desc("Enable FP math optimizations that assume no NaNs"),
cl::init(false));
CGBINDOPT(EnableNoNaNsFPMath);
static cl::opt<bool> EnableNoSignedZerosFPMath(
"enable-no-signed-zeros-fp-math",
cl::desc("Enable FP math optimizations that assume "
"the sign of 0 is insignificant"),
cl::init(false));
CGBINDOPT(EnableNoSignedZerosFPMath);
static cl::opt<bool> EnableNoTrappingFPMath(
"enable-no-trapping-fp-math",
cl::desc("Enable setting the FP exceptions build "
"attribute not to use exceptions"),
cl::init(false));
CGBINDOPT(EnableNoTrappingFPMath);
CodeGen: Add -denormal-fp-math-f32 flag Make the set of FP related attributes and command flags closer.
2019-12-04 17:04:14 +08:00
static const auto DenormFlagEnumOptions =
cl::values(clEnumValN(DenormalMode::IEEE, "ieee",
"IEEE 754 denormal numbers"),
clEnumValN(DenormalMode::PreserveSign, "preserve-sign",
"the sign of a flushed-to-zero number is preserved "
"in the sign of 0"),
clEnumValN(DenormalMode::PositiveZero, "positive-zero",
"denormals are flushed to positive zero"));
// FIXME: Doesn't have way to specify separate input and output modes.
Fix denormal-fp-math flag and attribute interaction Make these behave the same way unsafe-fp-math and co. The command line flag should add the attribute to functions that do not already have it, and leave existing attributes. The attribute is the actual implementation, but the flag is useful in some testing situations. AMDGPU has a variety of tests with denormals enabled/disabled that would require a painful level of test duplication without a flag. This doesn't expose setting the separate input/output modes, or add a flag for the f32 version yet. Tests will be included in future patch.
2020-03-12 05:12:20 +08:00
static cl::opt<DenormalMode::DenormalModeKind> DenormalFPMath(
CodeGen: Add -denormal-fp-math-f32 flag Make the set of FP related attributes and command flags closer.
2019-12-04 17:04:14 +08:00
"denormal-fp-math",
cl::desc("Select which denormal numbers the code is permitted to require"),
cl::init(DenormalMode::IEEE),
DenormFlagEnumOptions);
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
CGBINDOPT(DenormalFPMath);
CodeGen: Add -denormal-fp-math-f32 flag Make the set of FP related attributes and command flags closer.
2019-12-04 17:04:14 +08:00
static cl::opt<DenormalMode::DenormalModeKind> DenormalFP32Math(
"denormal-fp-math-f32",
cl::desc("Select which denormal numbers the code is permitted to require for float"),
cl::init(DenormalMode::Invalid),
DenormFlagEnumOptions);
CGBINDOPT(DenormalFP32Math);
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
static cl::opt<bool> EnableHonorSignDependentRoundingFPMath(
"enable-sign-dependent-rounding-fp-math", cl::Hidden,
cl::desc("Force codegen to assume rounding mode can change dynamically"),
cl::init(false));
CGBINDOPT(EnableHonorSignDependentRoundingFPMath);
static cl::opt<FloatABI::ABIType> FloatABIForCalls(
"float-abi", cl::desc("Choose float ABI type"),
cl::init(FloatABI::Default),
cl::values(clEnumValN(FloatABI::Default, "default",
"Target default float ABI type"),
clEnumValN(FloatABI::Soft, "soft",
"Soft float ABI (implied by -soft-float)"),
clEnumValN(FloatABI::Hard, "hard",
"Hard float ABI (uses FP registers)")));
CGBINDOPT(FloatABIForCalls);
static cl::opt<FPOpFusion::FPOpFusionMode> FuseFPOps(
"fp-contract", cl::desc("Enable aggressive formation of fused FP ops"),
cl::init(FPOpFusion::Standard),
cl::values(
clEnumValN(FPOpFusion::Fast, "fast",
"Fuse FP ops whenever profitable"),
clEnumValN(FPOpFusion::Standard, "on", "Only fuse 'blessed' FP ops."),
clEnumValN(FPOpFusion::Strict, "off",
"Only fuse FP ops when the result won't be affected.")));
CGBINDOPT(FuseFPOps);
static cl::opt<bool> DontPlaceZerosInBSS(
"nozero-initialized-in-bss",
cl::desc("Don't place zero-initialized symbols into bss section"),
cl::init(false));
CGBINDOPT(DontPlaceZerosInBSS);
[AIX] Add mabi=vec-extabi options to enable the AIX extended and default vector ABIs. Added support for the options mabi=vec-extabi and mabi=vec-default which are analogous to qvecnvol and qnovecnvol when using XL on AIX. The extended Altivec ABI on AIX is enabled using mabi=vec-extabi in clang and vec-extabi in llc. Reviewed By: Xiangling_L, DiggerLin Differential Revision: https://reviews.llvm.org/D89684
2020-11-25 07:11:46 +08:00
static cl::opt<bool> EnableAIXExtendedAltivecABI(
"vec-extabi", cl::desc("Enable the AIX Extended Altivec ABI."),
cl::init(false));
CGBINDOPT(EnableAIXExtendedAltivecABI);
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
static cl::opt<bool> EnableGuaranteedTailCallOpt(
"tailcallopt",
cl::desc(
"Turn fastcc calls into tail calls by (potentially) changing ABI."),
cl::init(false));
CGBINDOPT(EnableGuaranteedTailCallOpt);
static cl::opt<bool> DisableTailCalls(
"disable-tail-calls", cl::desc("Never emit tail calls"), cl::init(false));
CGBINDOPT(DisableTailCalls);
static cl::opt<bool> StackSymbolOrdering(
"stack-symbol-ordering", cl::desc("Order local stack symbols."),
cl::init(true));
CGBINDOPT(StackSymbolOrdering);
static cl::opt<unsigned> OverrideStackAlignment(
"stack-alignment", cl::desc("Override default stack alignment"),
cl::init(0));
CGBINDOPT(OverrideStackAlignment);
static cl::opt<bool> StackRealign(
"stackrealign",
cl::desc("Force align the stack to the minimum alignment"),
cl::init(false));
CGBINDOPT(StackRealign);
static cl::opt<std::string> TrapFuncName(
"trap-func", cl::Hidden,
cl::desc("Emit a call to trap function rather than a trap instruction"),
cl::init(""));
CGBINDOPT(TrapFuncName);
static cl::opt<bool> UseCtors("use-ctors",
cl::desc("Use .ctors instead of .init_array."),
cl::init(false));
CGBINDOPT(UseCtors);
static cl::opt<bool> RelaxELFRelocations(
"relax-elf-relocations",
cl::desc(
"Emit GOTPCRELX/REX_GOTPCRELX instead of GOTPCREL on x86-64 ELF"),
cl::init(false));
CGBINDOPT(RelaxELFRelocations);
static cl::opt<bool> DataSections(
"data-sections", cl::desc("Emit data into separate sections"),
cl::init(false));
CGBINDOPT(DataSections);
static cl::opt<bool> FunctionSections(
"function-sections", cl::desc("Emit functions into separate sections"),
cl::init(false));
CGBINDOPT(FunctionSections);
[AIX] add new option -mignore-xcoff-visibility SUMMARY: In IBM compiler xlclang , there is an option -fnovisibility which suppresses visibility. For more details see: https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_visibility.html. We need to add the option -mignore-xcoff-visibility for compatibility with the IBM AIX OS (as the option is enabled by default in AIX). With this option llvm does not emit any visibility attribute to ASM or XCOFF object file. The option only work on the AIX OS, for other non-AIX OS using the option will report an unsupported options error. In AIX OS: 1.1 the option -mignore-xcoff-visibility is enabled by default , if there is not -fvisibility=* and -mignore-xcoff-visibility explicitly in the clang command . 1.2 if there is -fvisibility=* explicitly but not -mignore-xcoff-visibility explicitly in the clang command. it will generate visibility attributes. 1.3 if there are both -fvisibility=* and -mignore-xcoff-visibility explicitly in the clang command. The option "-mignore-xcoff-visibility" wins , it do not emit the visibility attribute. The option -mignore-xcoff-visibility has no effect on visibility attribute when compile with -emit-llvm option to generated LLVM IR. Reviewer: daltenty,Jason Liu Differential Revision: https://reviews.llvm.org/D87451
2020-10-08 21:34:58 +08:00
static cl::opt<bool> IgnoreXCOFFVisibility(
"ignore-xcoff-visibility",
cl::desc("Not emit the visibility attribute for asm in AIX OS or give "
"all symbols 'unspecified' visibility in XCOFF object file"),
cl::init(false));
CGBINDOPT(IgnoreXCOFFVisibility);
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
static cl::opt<std::string> BBSections(
Rename basic block sections options to be consistent. D68049 created options for basic block sections: -fbasic-block-sections=, -funique-basic-block-section-names. Rename options in llc and lld (--lto-) to be consistent. Specifically, + Rename basicblock-sections to basic-block-sections + Rename unique-bb-section-names to unique-basic-block-section-names Differential Revision: https://reviews.llvm.org/D84462
2020-08-01 02:14:49 +08:00
"basic-block-sections",
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
cl::desc("Emit basic blocks into separate sections"),
cl::value_desc("all | <function list (file)> | labels | none"),
cl::init("none"));
CGBINDOPT(BBSections);
[X86] Support customizing stack protector guard Reviewed By: nickdesaulniers, MaskRay Differential Revision: https://reviews.llvm.org/D88631
2020-10-22 09:46:42 +08:00
static cl::opt<std::string> StackProtectorGuard(
"stack-protector-guard", cl::desc("Stack protector guard mode"),
cl::init("none"));
CGBINDOPT(StackProtectorGuard);
static cl::opt<std::string> StackProtectorGuardReg(
"stack-protector-guard-reg", cl::desc("Stack protector guard register"),
cl::init("none"));
CGBINDOPT(StackProtectorGuardReg);
static cl::opt<unsigned> StackProtectorGuardOffset(
"stack-protector-guard-offset", cl::desc("Stack protector guard offset"),
cl::init((unsigned)-1));
CGBINDOPT(StackProtectorGuardOffset);
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
static cl::opt<unsigned> TLSSize(
"tls-size", cl::desc("Bit size of immediate TLS offsets"), cl::init(0));
CGBINDOPT(TLSSize);
static cl::opt<bool> EmulatedTLS(
"emulated-tls", cl::desc("Use emulated TLS model"), cl::init(false));
CGBINDOPT(EmulatedTLS);
static cl::opt<bool> UniqueSectionNames(
"unique-section-names", cl::desc("Give unique names to every section"),
cl::init(true));
CGBINDOPT(UniqueSectionNames);
Options for Basic Block Sections, enabled in D68063 and D73674. This patch adds clang options: -fbasic-block-sections={all,<filename>,labels,none} and -funique-basic-block-section-names. LLVM Support for basic block sections is already enabled. + -fbasic-block-sections={all, <file>, labels, none} : Enables/Disables basic block sections for all or a subset of basic blocks. "labels" only enables basic block symbols. + -funique-basic-block-section-names: Enables unique section names for basic block sections, disabled by default. Differential Revision: https://reviews.llvm.org/D68049
2020-06-02 14:17:29 +08:00
static cl::opt<bool> UniqueBasicBlockSectionNames(
Rename basic block sections options to be consistent. D68049 created options for basic block sections: -fbasic-block-sections=, -funique-basic-block-section-names. Rename options in llc and lld (--lto-) to be consistent. Specifically, + Rename basicblock-sections to basic-block-sections + Rename unique-bb-section-names to unique-basic-block-section-names Differential Revision: https://reviews.llvm.org/D84462
2020-08-01 02:14:49 +08:00
"unique-basic-block-section-names",
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
cl::desc("Give unique names to every basic block section"),
cl::init(false));
Options for Basic Block Sections, enabled in D68063 and D73674. This patch adds clang options: -fbasic-block-sections={all,<filename>,labels,none} and -funique-basic-block-section-names. LLVM Support for basic block sections is already enabled. + -fbasic-block-sections={all, <file>, labels, none} : Enables/Disables basic block sections for all or a subset of basic blocks. "labels" only enables basic block symbols. + -funique-basic-block-section-names: Enables unique section names for basic block sections, disabled by default. Differential Revision: https://reviews.llvm.org/D68049
2020-06-02 14:17:29 +08:00
CGBINDOPT(UniqueBasicBlockSectionNames);
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
static cl::opt<EABI> EABIVersion(
"meabi", cl::desc("Set EABI type (default depends on triple):"),
cl::init(EABI::Default),
cl::values(
clEnumValN(EABI::Default, "default", "Triple default EABI version"),
clEnumValN(EABI::EABI4, "4", "EABI version 4"),
clEnumValN(EABI::EABI5, "5", "EABI version 5"),
clEnumValN(EABI::GNU, "gnu", "EABI GNU")));
CGBINDOPT(EABIVersion);
static cl::opt<DebuggerKind> DebuggerTuningOpt(
"debugger-tune", cl::desc("Tune debug info for a particular debugger"),
cl::init(DebuggerKind::Default),
cl::values(
clEnumValN(DebuggerKind::GDB, "gdb", "gdb"),
clEnumValN(DebuggerKind::LLDB, "lldb", "lldb"),
clEnumValN(DebuggerKind::SCE, "sce", "SCE targets (e.g. PS4)")));
CGBINDOPT(DebuggerTuningOpt);
static cl::opt<bool> EnableStackSizeSection(
"stack-size-section",
cl::desc("Emit a section containing stack size metadata"),
cl::init(false));
CGBINDOPT(EnableStackSizeSection);
static cl::opt<bool> EnableAddrsig(
"addrsig", cl::desc("Emit an address-significance table"),
cl::init(false));
CGBINDOPT(EnableAddrsig);
static cl::opt<bool> EmitCallSiteInfo(
"emit-call-site-info",
cl::desc(
"Emit call site debug information, if debug information is enabled."),
cl::init(false));
CGBINDOPT(EmitCallSiteInfo);
static cl::opt<bool> EnableDebugEntryValues(
"debug-entry-values",
Reland D73534: [DebugInfo] Enable the debug entry values feature by default The issue that was causing the build failures was fixed with the D76164.
2020-03-19 19:13:18 +08:00
cl::desc("Enable debug info for the debug entry values."),
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
cl::init(false));
CGBINDOPT(EnableDebugEntryValues);
[CSSPGO] Pseudo probes for function calls. An indirect call site needs to be probed for its potential call targets. With CSSPGO a direct call also needs a probe so that a calling context can be represented by a stack of callsite probes. Unlike pseudo probes for basic blocks that are in form of standalone intrinsic call instructions, pseudo probes for callsites have to be attached to the call instruction, thus a separate instruction would not work. One possible way of attaching a probe to a call instruction is to use a special metadata that carries information about the probe. The special metadata will have to make its way through the optimization pipeline down to object emission. This requires additional efforts to maintain the metadata in various places. Given that the `!dbg` metadata is a first-class metadata and has all essential support in place , leveraging the `!dbg` metadata as a channel to encode pseudo probe information is probably the easiest solution. With the requirement of not inflating `!dbg` metadata that is allocated for almost every instruction, we found that the 32-bit DWARF discriminator field which mainly serves AutoFDO can be reused for pseudo probes. DWARF discriminators distinguish identical source locations between instructions and with pseudo probes such support is not required. In this change we are using the discriminator field to encode the ID and type of a callsite probe and the encoded value will be unpacked and consumed right before object emission. When a callsite is inlined, the callsite discriminator field will go with the inlined instructions. The `!dbg` metadata of an inlined instruction is in form of a scope stack. The top of the stack is the instruction's original `!dbg` metadata and the bottom of the stack is for the original callsite of the top-level inliner. Except for the top of the stack, all other elements of the stack actually refer to the nested inlined callsites whose discriminator field (which actually represents a calliste probe) can be used together to represent the inline context of an inlined PseudoProbeInst or CallInst. To avoid collision with the baseline AutoFDO in various places that handles dwarf discriminators where a check against the `-pseudo-probe-for-profiling` switch is not available, a special encoding scheme is used to tell apart a pseudo probe discriminator from a regular discriminator. For the regular discriminator, if all lowest 3 bits are non-zero, it means the discriminator is basically empty and all higher 29 bits can be reversed for pseudo probe use. Callsite pseudo probes are inserted in `SampleProfileProbePass` and a target-independent MIR pass `PseudoProbeInserter` is added to unpack the probe ID/type from `!dbg`. Note that with this work the switch -debug-info-for-profiling will not work with -pseudo-probe-for-profiling anymore. They cannot be used at the same time. Reviewed By: wmi Differential Revision: https://reviews.llvm.org/D91756
2020-12-02 13:44:06 +08:00
static cl::opt<bool> PseudoProbeForProfiling(
"pseudo-probe-for-profiling", cl::desc("Emit pseudo probes for AutoFDO"),
cl::init(false));
CGBINDOPT(PseudoProbeForProfiling);
[LiveDebugValues] Add switches for using instr-ref variable locations This patch adds the -Xclang option "-fexperimental-debug-variable-locations" and same LLVM CodeGen option, to pick which variable location tracking solution to use. Right now all the switch does is pick which LiveDebugValues implementation to use, the normal VarLoc one or the instruction referencing one in rGae6f78824031. Over time, the aim is to add fragments of support in aid of the value-tracking RFC: http://lists.llvm.org/pipermail/llvm-dev/2020-February/139440.html also controlled by this command line switch. That will slowly move variable locations to be defined by an instruction calculating a value, and a DBG_INSTR_REF instruction referring to that value. Thus, this is going to grow into a "use the new kind of variable locations" switch, rather than just "use the new LiveDebugValues implementation". Differential Revision: https://reviews.llvm.org/D83048
2020-08-25 21:23:14 +08:00
static cl::opt<bool> ValueTrackingVariableLocations(
"experimental-debug-variable-locations",
cl::desc("Use experimental new value-tracking variable locations"),
cl::init(false));
CGBINDOPT(ValueTrackingVariableLocations);
[llvm][CodeGen] Machine Function Splitter We introduce a codegen optimization pass which splits functions into hot and cold parts. This pass leverages the basic block sections feature recently introduced in LLVM from the Propeller project. The pass targets functions with profile coverage, identifies cold blocks and moves them to a separate section. The linker groups all cold blocks across functions together, decreasing fragmentation and improving icache and itlb utilization. We evaluated the Machine Function Splitter pass on clang bootstrap and SPECInt 2017. For clang bootstrap we observe a mean 2.33% runtime improvement with a ~32% reduction in itlb and stlb misses. Additionally, L1 icache misses reduced by 9.5% while L2 instruction misses reduced by 20%. For SPECInt we report the change in IntRate the C/C++ benchmarks. All benchmarks apart from mcf and x264 improve, on average by 0.6% with the max for deepsjeng at 1.6%. Benchmark % Change 500.perlbench_r 0.78 502.gcc_r 0.82 505.mcf_r -0.30 520.omnetpp_r 0.18 523.xalancbmk_r 0.37 525.x264_r -0.46 531.deepsjeng_r 1.61 541.leela_r 0.83 557.xz_r 0.15 Differential Revision: https://reviews.llvm.org/D85368
2020-08-06 06:34:31 +08:00
static cl::opt<bool> EnableMachineFunctionSplitter(
"split-machine-functions",
cl::desc("Split out cold basic blocks from machine functions based on "
"profile information"),
cl::init(false));
CGBINDOPT(EnableMachineFunctionSplitter);
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
static cl::opt<bool> ForceDwarfFrameSection(
"force-dwarf-frame-section",
cl::desc("Always emit a debug frame section."), cl::init(false));
CGBINDOPT(ForceDwarfFrameSection);
[xray] Option to omit the function index Summary: Add a flag to omit the xray_fn_idx to cut size overhead and relocations roughly in half at the cost of reduced performance for single function patching. Minor additions to compiler-rt support per-function patching without the index. Reviewers: dberris, MaskRay, johnislarry Subscribers: hiraditya, arphaman, cfe-commits, #sanitizers, llvm-commits Tags: #clang, #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D81995
2020-06-17 08:36:11 +08:00
static cl::opt<bool> XRayOmitFunctionIndex(
"no-xray-index", cl::desc("Don't emit xray_fn_idx section"),
cl::init(false));
CGBINDOPT(XRayOmitFunctionIndex);
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
#undef CGBINDOPT
mc::RegisterMCTargetOptionsFlags();
}
llvm::BasicBlockSection
codegen::getBBSectionsMode(llvm::TargetOptions &Options) {
if (getBBSections() == "all")
return BasicBlockSection::All;
else if (getBBSections() == "labels")
return BasicBlockSection::Labels;
else if (getBBSections() == "none")
return BasicBlockSection::None;
else {
ErrorOr<std::unique_ptr<MemoryBuffer>> MBOrErr =
MemoryBuffer::getFile(getBBSections());
if (!MBOrErr) {
errs() << "Error loading basic block sections function list file: "
<< MBOrErr.getError().message() << "\n";
} else {
Options.BBSectionsFuncListBuf = std::move(*MBOrErr);
}
return BasicBlockSection::List;
}
}
[X86] Support customizing stack protector guard Reviewed By: nickdesaulniers, MaskRay Differential Revision: https://reviews.llvm.org/D88631
2020-10-22 09:46:42 +08:00
llvm::StackProtectorGuards
codegen::getStackProtectorGuardMode(llvm::TargetOptions &Options) {
if (getStackProtectorGuard() == "tls")
return StackProtectorGuards::TLS;
if (getStackProtectorGuard() == "global")
return StackProtectorGuards::Global;
if (getStackProtectorGuard() != "none") {
ErrorOr<std::unique_ptr<MemoryBuffer>> MBOrErr =
MemoryBuffer::getFile(getStackProtectorGuard());
if (!MBOrErr)
errs() << "error illegal stack protector guard mode: "
<< MBOrErr.getError().message() << "\n";
else
Options.BBSectionsFuncListBuf = std::move(*MBOrErr);
}
return StackProtectorGuards::None;
}
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
// Common utility function tightly tied to the options listed here. Initializes
// a TargetOptions object with CodeGen flags and returns it.
[AIX] Turn -fdata-sections on by default in Clang Summary: This patch does the following: 1. Make InitTargetOptionsFromCodeGenFlags() accepts Triple as a parameter, because some options' default value is triple dependant. 2. DataSections is turned on by default on AIX for llc. 3. Test cases change accordingly because of the default behaviour change. 4. Clang Driver passes in -fdata-sections by default on AIX. Reviewed By: MaskRay, DiggerLin Differential Revision: https://reviews.llvm.org/D88737
2020-10-14 23:55:55 +08:00
TargetOptions
codegen::InitTargetOptionsFromCodeGenFlags(const Triple &TheTriple) {
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
TargetOptions Options;
Options.AllowFPOpFusion = getFuseFPOps();
Options.UnsafeFPMath = getEnableUnsafeFPMath();
Options.NoInfsFPMath = getEnableNoInfsFPMath();
Options.NoNaNsFPMath = getEnableNoNaNsFPMath();
Options.NoSignedZerosFPMath = getEnableNoSignedZerosFPMath();
Options.NoTrappingFPMath = getEnableNoTrappingFPMath();
Fix denormal-fp-math flag and attribute interaction Make these behave the same way unsafe-fp-math and co. The command line flag should add the attribute to functions that do not already have it, and leave existing attributes. The attribute is the actual implementation, but the flag is useful in some testing situations. AMDGPU has a variety of tests with denormals enabled/disabled that would require a painful level of test duplication without a flag. This doesn't expose setting the separate input/output modes, or add a flag for the f32 version yet. Tests will be included in future patch.
2020-03-12 05:12:20 +08:00
DenormalMode::DenormalModeKind DenormKind = getDenormalFPMath();
// FIXME: Should have separate input and output flags
Options.setFPDenormalMode(DenormalMode(DenormKind, DenormKind));
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
Options.HonorSignDependentRoundingFPMathOption =
getEnableHonorSignDependentRoundingFPMath();
if (getFloatABIForCalls() != FloatABI::Default)
Options.FloatABIType = getFloatABIForCalls();
[AIX] Add mabi=vec-extabi options to enable the AIX extended and default vector ABIs. Added support for the options mabi=vec-extabi and mabi=vec-default which are analogous to qvecnvol and qnovecnvol when using XL on AIX. The extended Altivec ABI on AIX is enabled using mabi=vec-extabi in clang and vec-extabi in llc. Reviewed By: Xiangling_L, DiggerLin Differential Revision: https://reviews.llvm.org/D89684
2020-11-25 07:11:46 +08:00
Options.EnableAIXExtendedAltivecABI = getEnableAIXExtendedAltivecABI();
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
Options.NoZerosInBSS = getDontPlaceZerosInBSS();
Options.GuaranteedTailCallOpt = getEnableGuaranteedTailCallOpt();
Options.StackAlignmentOverride = getOverrideStackAlignment();
Options.StackSymbolOrdering = getStackSymbolOrdering();
Options.UseInitArray = !getUseCtors();
Options.RelaxELFRelocations = getRelaxELFRelocations();
[AIX] Turn -fdata-sections on by default in Clang Summary: This patch does the following: 1. Make InitTargetOptionsFromCodeGenFlags() accepts Triple as a parameter, because some options' default value is triple dependant. 2. DataSections is turned on by default on AIX for llc. 3. Test cases change accordingly because of the default behaviour change. 4. Clang Driver passes in -fdata-sections by default on AIX. Reviewed By: MaskRay, DiggerLin Differential Revision: https://reviews.llvm.org/D88737
2020-10-14 23:55:55 +08:00
Options.DataSections =
getExplicitDataSections().getValueOr(TheTriple.hasDefaultDataSections());
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
Options.FunctionSections = getFunctionSections();
[AIX] add new option -mignore-xcoff-visibility SUMMARY: In IBM compiler xlclang , there is an option -fnovisibility which suppresses visibility. For more details see: https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_visibility.html. We need to add the option -mignore-xcoff-visibility for compatibility with the IBM AIX OS (as the option is enabled by default in AIX). With this option llvm does not emit any visibility attribute to ASM or XCOFF object file. The option only work on the AIX OS, for other non-AIX OS using the option will report an unsupported options error. In AIX OS: 1.1 the option -mignore-xcoff-visibility is enabled by default , if there is not -fvisibility=* and -mignore-xcoff-visibility explicitly in the clang command . 1.2 if there is -fvisibility=* explicitly but not -mignore-xcoff-visibility explicitly in the clang command. it will generate visibility attributes. 1.3 if there are both -fvisibility=* and -mignore-xcoff-visibility explicitly in the clang command. The option "-mignore-xcoff-visibility" wins , it do not emit the visibility attribute. The option -mignore-xcoff-visibility has no effect on visibility attribute when compile with -emit-llvm option to generated LLVM IR. Reviewer: daltenty,Jason Liu Differential Revision: https://reviews.llvm.org/D87451
2020-10-08 21:34:58 +08:00
Options.IgnoreXCOFFVisibility = getIgnoreXCOFFVisibility();
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
Options.BBSections = getBBSectionsMode(Options);
Options.UniqueSectionNames = getUniqueSectionNames();
Options for Basic Block Sections, enabled in D68063 and D73674. This patch adds clang options: -fbasic-block-sections={all,<filename>,labels,none} and -funique-basic-block-section-names. LLVM Support for basic block sections is already enabled. + -fbasic-block-sections={all, <file>, labels, none} : Enables/Disables basic block sections for all or a subset of basic blocks. "labels" only enables basic block symbols. + -funique-basic-block-section-names: Enables unique section names for basic block sections, disabled by default. Differential Revision: https://reviews.llvm.org/D68049
2020-06-02 14:17:29 +08:00
Options.UniqueBasicBlockSectionNames = getUniqueBasicBlockSectionNames();
[X86] Support customizing stack protector guard Reviewed By: nickdesaulniers, MaskRay Differential Revision: https://reviews.llvm.org/D88631
2020-10-22 09:46:42 +08:00
Options.StackProtectorGuard = getStackProtectorGuardMode(Options);
Options.StackProtectorGuardOffset = getStackProtectorGuardOffset();
Options.StackProtectorGuardReg = getStackProtectorGuardReg();
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
Options.TLSSize = getTLSSize();
Options.EmulatedTLS = getEmulatedTLS();
Options.ExplicitEmulatedTLS = EmulatedTLSView->getNumOccurrences() > 0;
Options.ExceptionModel = getExceptionModel();
Options.EmitStackSizeSection = getEnableStackSizeSection();
[llvm][CodeGen] Machine Function Splitter We introduce a codegen optimization pass which splits functions into hot and cold parts. This pass leverages the basic block sections feature recently introduced in LLVM from the Propeller project. The pass targets functions with profile coverage, identifies cold blocks and moves them to a separate section. The linker groups all cold blocks across functions together, decreasing fragmentation and improving icache and itlb utilization. We evaluated the Machine Function Splitter pass on clang bootstrap and SPECInt 2017. For clang bootstrap we observe a mean 2.33% runtime improvement with a ~32% reduction in itlb and stlb misses. Additionally, L1 icache misses reduced by 9.5% while L2 instruction misses reduced by 20%. For SPECInt we report the change in IntRate the C/C++ benchmarks. All benchmarks apart from mcf and x264 improve, on average by 0.6% with the max for deepsjeng at 1.6%. Benchmark % Change 500.perlbench_r 0.78 502.gcc_r 0.82 505.mcf_r -0.30 520.omnetpp_r 0.18 523.xalancbmk_r 0.37 525.x264_r -0.46 531.deepsjeng_r 1.61 541.leela_r 0.83 557.xz_r 0.15 Differential Revision: https://reviews.llvm.org/D85368
2020-08-06 06:34:31 +08:00
Options.EnableMachineFunctionSplitter = getEnableMachineFunctionSplitter();
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
Options.EmitAddrsig = getEnableAddrsig();
Options.EmitCallSiteInfo = getEmitCallSiteInfo();
Options.EnableDebugEntryValues = getEnableDebugEntryValues();
[CSSPGO] Pseudo probes for function calls. An indirect call site needs to be probed for its potential call targets. With CSSPGO a direct call also needs a probe so that a calling context can be represented by a stack of callsite probes. Unlike pseudo probes for basic blocks that are in form of standalone intrinsic call instructions, pseudo probes for callsites have to be attached to the call instruction, thus a separate instruction would not work. One possible way of attaching a probe to a call instruction is to use a special metadata that carries information about the probe. The special metadata will have to make its way through the optimization pipeline down to object emission. This requires additional efforts to maintain the metadata in various places. Given that the `!dbg` metadata is a first-class metadata and has all essential support in place , leveraging the `!dbg` metadata as a channel to encode pseudo probe information is probably the easiest solution. With the requirement of not inflating `!dbg` metadata that is allocated for almost every instruction, we found that the 32-bit DWARF discriminator field which mainly serves AutoFDO can be reused for pseudo probes. DWARF discriminators distinguish identical source locations between instructions and with pseudo probes such support is not required. In this change we are using the discriminator field to encode the ID and type of a callsite probe and the encoded value will be unpacked and consumed right before object emission. When a callsite is inlined, the callsite discriminator field will go with the inlined instructions. The `!dbg` metadata of an inlined instruction is in form of a scope stack. The top of the stack is the instruction's original `!dbg` metadata and the bottom of the stack is for the original callsite of the top-level inliner. Except for the top of the stack, all other elements of the stack actually refer to the nested inlined callsites whose discriminator field (which actually represents a calliste probe) can be used together to represent the inline context of an inlined PseudoProbeInst or CallInst. To avoid collision with the baseline AutoFDO in various places that handles dwarf discriminators where a check against the `-pseudo-probe-for-profiling` switch is not available, a special encoding scheme is used to tell apart a pseudo probe discriminator from a regular discriminator. For the regular discriminator, if all lowest 3 bits are non-zero, it means the discriminator is basically empty and all higher 29 bits can be reversed for pseudo probe use. Callsite pseudo probes are inserted in `SampleProfileProbePass` and a target-independent MIR pass `PseudoProbeInserter` is added to unpack the probe ID/type from `!dbg`. Note that with this work the switch -debug-info-for-profiling will not work with -pseudo-probe-for-profiling anymore. They cannot be used at the same time. Reviewed By: wmi Differential Revision: https://reviews.llvm.org/D91756
2020-12-02 13:44:06 +08:00
Options.PseudoProbeForProfiling = getPseudoProbeForProfiling();
[LiveDebugValues] Add switches for using instr-ref variable locations This patch adds the -Xclang option "-fexperimental-debug-variable-locations" and same LLVM CodeGen option, to pick which variable location tracking solution to use. Right now all the switch does is pick which LiveDebugValues implementation to use, the normal VarLoc one or the instruction referencing one in rGae6f78824031. Over time, the aim is to add fragments of support in aid of the value-tracking RFC: http://lists.llvm.org/pipermail/llvm-dev/2020-February/139440.html also controlled by this command line switch. That will slowly move variable locations to be defined by an instruction calculating a value, and a DBG_INSTR_REF instruction referring to that value. Thus, this is going to grow into a "use the new kind of variable locations" switch, rather than just "use the new LiveDebugValues implementation". Differential Revision: https://reviews.llvm.org/D83048
2020-08-25 21:23:14 +08:00
Options.ValueTrackingVariableLocations = getValueTrackingVariableLocations();
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
Options.ForceDwarfFrameSection = getForceDwarfFrameSection();
[xray] Option to omit the function index Summary: Add a flag to omit the xray_fn_idx to cut size overhead and relocations roughly in half at the cost of reduced performance for single function patching. Minor additions to compiler-rt support per-function patching without the index. Reviewers: dberris, MaskRay, johnislarry Subscribers: hiraditya, arphaman, cfe-commits, #sanitizers, llvm-commits Tags: #clang, #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D81995
2020-06-17 08:36:11 +08:00
Options.XRayOmitFunctionIndex = getXRayOmitFunctionIndex();
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
Options.MCOptions = mc::InitMCTargetOptionsFromFlags();
Options.ThreadModel = getThreadModel();
Options.EABIVersion = getEABIVersion();
Options.DebuggerTuning = getDebuggerTuningOpt();
return Options;
}
std::string codegen::getCPUStr() {
// If user asked for the 'native' CPU, autodetect here. If autodection fails,
// this will set the CPU to an empty string which tells the target to
// pick a basic default.
if (getMCPU() == "native")
return std::string(sys::getHostCPUName());
return getMCPU();
}
std::string codegen::getFeaturesStr() {
SubtargetFeatures Features;
// If user asked for the 'native' CPU, we need to autodetect features.
// This is necessary for x86 where the CPU might not support all the
// features the autodetected CPU name lists in the target. For example,
// not all Sandybridge processors support AVX.
if (getMCPU() == "native") {
StringMap<bool> HostFeatures;
if (sys::getHostCPUFeatures(HostFeatures))
for (auto &F : HostFeatures)
Features.AddFeature(F.first(), F.second);
}
for (auto const &MAttr : getMAttrs())
Features.AddFeature(MAttr);
return Features.getString();
}
std::vector<std::string> codegen::getFeatureList() {
SubtargetFeatures Features;
// If user asked for the 'native' CPU, we need to autodetect features.
// This is necessary for x86 where the CPU might not support all the
// features the autodetected CPU name lists in the target. For example,
// not all Sandybridge processors support AVX.
if (getMCPU() == "native") {
StringMap<bool> HostFeatures;
if (sys::getHostCPUFeatures(HostFeatures))
for (auto &F : HostFeatures)
Features.AddFeature(F.first(), F.second);
}
for (auto const &MAttr : getMAttrs())
Features.AddFeature(MAttr);
return Features.getFeatures();
}
void codegen::renderBoolStringAttr(AttrBuilder &B, StringRef Name, bool Val) {
B.addAttribute(Name, Val ? "true" : "false");
}
#define HANDLE_BOOL_ATTR(CL, AttrName) \
do { \
if (CL->getNumOccurrences() > 0 && !F.hasFnAttribute(AttrName)) \
renderBoolStringAttr(NewAttrs, AttrName, *CL); \
} while (0)
/// Set function attributes of function \p F based on CPU, Features, and command
/// line flags.
void codegen::setFunctionAttributes(StringRef CPU, StringRef Features,
Function &F) {
auto &Ctx = F.getContext();
AttributeList Attrs = F.getAttributes();
AttrBuilder NewAttrs;
if (!CPU.empty() && !F.hasFnAttribute("target-cpu"))
NewAttrs.addAttribute("target-cpu", CPU);
if (!Features.empty()) {
// Append the command line features to any that are already on the function.
StringRef OldFeatures =
F.getFnAttribute("target-features").getValueAsString();
if (OldFeatures.empty())
NewAttrs.addAttribute("target-features", Features);
else {
SmallString<256> Appended(OldFeatures);
Appended.push_back(',');
Appended.append(Features);
NewAttrs.addAttribute("target-features", Appended);
}
}
if (FramePointerUsageView->getNumOccurrences() > 0 &&
!F.hasFnAttribute("frame-pointer")) {
if (getFramePointerUsage() == FramePointer::All)
NewAttrs.addAttribute("frame-pointer", "all");
else if (getFramePointerUsage() == FramePointer::NonLeaf)
NewAttrs.addAttribute("frame-pointer", "non-leaf");
else if (getFramePointerUsage() == FramePointer::None)
NewAttrs.addAttribute("frame-pointer", "none");
}
if (DisableTailCallsView->getNumOccurrences() > 0)
NewAttrs.addAttribute("disable-tail-calls",
toStringRef(getDisableTailCalls()));
if (getStackRealign())
NewAttrs.addAttribute("stackrealign");
HANDLE_BOOL_ATTR(EnableUnsafeFPMathView, "unsafe-fp-math");
HANDLE_BOOL_ATTR(EnableNoInfsFPMathView, "no-infs-fp-math");
HANDLE_BOOL_ATTR(EnableNoNaNsFPMathView, "no-nans-fp-math");
HANDLE_BOOL_ATTR(EnableNoSignedZerosFPMathView, "no-signed-zeros-fp-math");
Fix denormal-fp-math flag and attribute interaction Make these behave the same way unsafe-fp-math and co. The command line flag should add the attribute to functions that do not already have it, and leave existing attributes. The attribute is the actual implementation, but the flag is useful in some testing situations. AMDGPU has a variety of tests with denormals enabled/disabled that would require a painful level of test duplication without a flag. This doesn't expose setting the separate input/output modes, or add a flag for the f32 version yet. Tests will be included in future patch.
2020-03-12 05:12:20 +08:00
if (DenormalFPMathView->getNumOccurrences() > 0 &&
!F.hasFnAttribute("denormal-fp-math")) {
DenormalMode::DenormalModeKind DenormKind = getDenormalFPMath();
// FIXME: Command line flag should expose separate input/output modes.
NewAttrs.addAttribute("denormal-fp-math",
DenormalMode(DenormKind, DenormKind).str());
}
CodeGen: Add -denormal-fp-math-f32 flag Make the set of FP related attributes and command flags closer.
2019-12-04 17:04:14 +08:00
if (DenormalFP32MathView->getNumOccurrences() > 0 &&
!F.hasFnAttribute("denormal-fp-math-f32")) {
// FIXME: Command line flag should expose separate input/output modes.
DenormalMode::DenormalModeKind DenormKind = getDenormalFP32Math();
NewAttrs.addAttribute(
"denormal-fp-math-f32",
DenormalMode(DenormKind, DenormKind).str());
}
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain cl::opt with static storage. These headers are meant to be incuded by tools to make it easier to parametrize codegen/mc. However, these headers are also included in at least two libraries: lldCommon and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference to the options, and lldCommon holds another reference. Linking the two in a single executable, as zig does[0], results in a double registration. This patch explores an other approach: the .inc files are moved to regular files, and the registration happens on-demand through static declaration of options in the constructor of a static object. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5 Differential Revision: https://reviews.llvm.org/D75579
2020-03-04 07:47:43 +08:00
if (TrapFuncNameView->getNumOccurrences() > 0)
for (auto &B : F)
for (auto &I : B)
if (auto *Call = dyn_cast<CallInst>(&I))
if (const auto *F = Call->getCalledFunction())
if (F->getIntrinsicID() == Intrinsic::debugtrap ||
F->getIntrinsicID() == Intrinsic::trap)
Call->addAttribute(
AttributeList::FunctionIndex,
Attribute::get(Ctx, "trap-func-name", getTrapFuncName()));
// Let NewAttrs override Attrs.
F.setAttributes(
Attrs.addAttributes(Ctx, AttributeList::FunctionIndex, NewAttrs));
}
/// Set function attributes of functions in Module M based on CPU,
/// Features, and command line flags.
void codegen::setFunctionAttributes(StringRef CPU, StringRef Features,
Module &M) {
for (Function &F : M)
setFunctionAttributes(CPU, Features, F);
}