llvm-project/llvm/lib/IR/Globals.cpp

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

652 lines
23 KiB
C++
Raw Normal View History

//===-- Globals.cpp - Implement the GlobalValue & GlobalVariable class ----===//
//
// 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 implements the GlobalValue & GlobalVariable classes for the IR
// library.
//
//===----------------------------------------------------------------------===//
#include "LLVMContextImpl.h"
#include "llvm/IR/ConstantRange.h"
#include "llvm/IR/Constants.h"
#include "llvm/IR/DerivedTypes.h"
#include "llvm/IR/GlobalAlias.h"
#include "llvm/IR/GlobalValue.h"
#include "llvm/IR/GlobalVariable.h"
#include "llvm/IR/MDBuilder.h"
#include "llvm/IR/Module.h"
#include "llvm/Support/Error.h"
#include "llvm/Support/ErrorHandling.h"
#include "llvm/Support/MD5.h"
#include "llvm/TargetParser/Triple.h"
using namespace llvm;
//===----------------------------------------------------------------------===//
// GlobalValue Class
//===----------------------------------------------------------------------===//
// GlobalValue should be a Constant, plus a type, a module, some flags, and an
// intrinsic ID. Add an assert to prevent people from accidentally growing
// GlobalValue while adding flags.
static_assert(sizeof(GlobalValue) ==
sizeof(Constant) + 2 * sizeof(void *) + 2 * sizeof(unsigned),
"unexpected GlobalValue size growth");
// GlobalObject adds a comdat.
static_assert(sizeof(GlobalObject) == sizeof(GlobalValue) + sizeof(void *),
"unexpected GlobalObject size growth");
bool GlobalValue::isMaterializable() const {
if (const Function *F = dyn_cast<Function>(this))
return F->isMaterializable();
return false;
}
Error GlobalValue::materialize() { return getParent()->materialize(this); }
/// Override destroyConstantImpl to make sure it doesn't get called on
/// GlobalValue's because they shouldn't be treated like other constants.
void GlobalValue::destroyConstantImpl() {
llvm_unreachable("You can't GV->destroyConstantImpl()!");
}
Value *GlobalValue::handleOperandChangeImpl(Value *From, Value *To) {
llvm_unreachable("Unsupported class for handleOperandChange()!");
}
/// copyAttributesFrom - copy all additional attributes (those not needed to
/// create a GlobalValue) from the GlobalValue Src to this one.
void GlobalValue::copyAttributesFrom(const GlobalValue *Src) {
setVisibility(Src->getVisibility());
IR: Introduce local_unnamed_addr attribute. If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
2016-06-14 21:01:22 +00:00
setUnnamedAddr(Src->getUnnamedAddr());
setThreadLocalMode(Src->getThreadLocalMode());
setDLLStorageClass(Src->getDLLStorageClass());
Represent runtime preemption in the IR. Currently we do not represent runtime preemption in the IR, which has several drawbacks: 1) The semantics of GlobalValues differ depending on the object file format you are targeting (as well as the relocation-model and -fPIE value). 2) We have no way of disabling inlining of run time interposable functions, since in the IR we only know if a function is link-time interposable. Because of this llvm cannot support elf-interposition semantics. 3) In LTO builds of executables we will have extra knowledge that a symbol resolved to a local definition and can't be preemptable, but have no way to propagate that knowledge through the compiler. This patch adds preemptability specifiers to the IR with the following meaning: dso_local --> means the compiler may assume the symbol will resolve to a definition within the current linkage unit and the symbol may be accessed directly even if the definition is not within this compilation unit. dso_preemptable --> means that the compiler must assume the GlobalValue may be replaced with a definition from outside the current linkage unit at runtime. To ease transitioning dso_preemptable is treated as a 'default' in that low-level codegen will still do the same checks it did previously to see if a symbol should be accessed indirectly. Eventually when IR producers emit the specifiers on all Globalvalues we can change dso_preemptable to mean 'always access indirectly', and remove the current logic. Differential Revision: https://reviews.llvm.org/D20217 llvm-svn: 316668
2017-10-26 15:00:26 +00:00
setDSOLocal(Src->isDSOLocal());
setPartition(Src->getPartition());
if (Src->hasSanitizerMetadata())
setSanitizerMetadata(Src->getSanitizerMetadata());
else
removeSanitizerMetadata();
}
GlobalValue::GUID GlobalValue::getGUID(StringRef GlobalName) {
return MD5Hash(GlobalName);
}
void GlobalValue::removeFromParent() {
switch (getValueID()) {
#define HANDLE_GLOBAL_VALUE(NAME) \
case Value::NAME##Val: \
return static_cast<NAME *>(this)->removeFromParent();
#include "llvm/IR/Value.def"
default:
break;
}
llvm_unreachable("not a global");
}
void GlobalValue::eraseFromParent() {
switch (getValueID()) {
#define HANDLE_GLOBAL_VALUE(NAME) \
case Value::NAME##Val: \
return static_cast<NAME *>(this)->eraseFromParent();
#include "llvm/IR/Value.def"
default:
break;
}
llvm_unreachable("not a global");
}
GlobalObject::~GlobalObject() { setComdat(nullptr); }
bool GlobalValue::isInterposable() const {
if (isInterposableLinkage(getLinkage()))
return true;
return getParent() && getParent()->getSemanticInterposition() &&
!isDSOLocal();
}
bool GlobalValue::canBenefitFromLocalAlias() const {
if (isTagged()) {
// Cannot create local aliases to MTE tagged globals. The address of a
// tagged global includes a tag that is assigned by the loader in the
// GOT.
return false;
}
// See AsmPrinter::getSymbolPreferLocal(). For a deduplicate comdat kind,
// references to a discarded local symbol from outside the group are not
// allowed, so avoid the local alias.
auto isDeduplicateComdat = [](const Comdat *C) {
return C && C->getSelectionKind() != Comdat::NoDeduplicate;
};
return hasDefaultVisibility() &&
GlobalObject::isExternalLinkage(getLinkage()) && !isDeclaration() &&
!isa<GlobalIFunc>(this) && !isDeduplicateComdat(getComdat());
}
const DataLayout &GlobalValue::getDataLayout() const {
return getParent()->getDataLayout();
}
void GlobalObject::setAlignment(MaybeAlign Align) {
assert((!Align || *Align <= MaximumAlignment) &&
"Alignment is greater than MaximumAlignment!");
unsigned AlignmentData = encode(Align);
unsigned OldData = getGlobalValueSubClassData();
setGlobalValueSubClassData((OldData & ~AlignmentMask) | AlignmentData);
assert(getAlign() == Align && "Alignment representation error!");
}
[reland][NFC] Transition GlobalObject alignment from MaybeAlign to Align This is a follow up on https://reviews.llvm.org/D142459#4081179. This first patch adds an overload to `GlobalObject::setAlignment` that accepts an `Align` type. This already handles most of the calls. This patch also converts a few call sites to the new type when this is safe. Here is the list of the remaining call sites: - [clang/lib/CodeGen/CodeGenModule.cpp:1688](https://github.com/llvm/llvm-project/blob/e195e6bad6706230a4b5fd4b5cc13de1f16f25cc/clang/lib/CodeGen/CodeGenModule.cpp#L1688) - [llvm/lib/AsmParser/LLParser.cpp:1309](https://github.com/llvm/llvm-project/blob/e195e6bad6706230a4b5fd4b5cc13de1f16f25cc/llvm/lib/AsmParser/LLParser.cpp#L1309) - [llvm/lib/AsmParser/LLParser.cpp:6050](https://github.com/llvm/llvm-project/blob/e195e6bad6706230a4b5fd4b5cc13de1f16f25cc/llvm/lib/AsmParser/LLParser.cpp#L6050) - [llvm/lib/Bitcode/Reader/BitcodeReader.cpp:3871](https://github.com/llvm/llvm-project/blob/e195e6bad6706230a4b5fd4b5cc13de1f16f25cc/llvm/lib/Bitcode/Reader/BitcodeReader.cpp#L3871) - [llvm/lib/Bitcode/Reader/BitcodeReader.cpp:4030](https://github.com/llvm/llvm-project/blob/e195e6bad6706230a4b5fd4b5cc13de1f16f25cc/llvm/lib/Bitcode/Reader/BitcodeReader.cpp#L4030) - [llvm/lib/IR/Core.cpp:2018](https://github.com/llvm/llvm-project/blob/e195e6bad6706230a4b5fd4b5cc13de1f16f25cc/llvm/lib/IR/Core.cpp#L2018) - [llvm/lib/IR/Globals.cpp:141](https://github.com/llvm/llvm-project/blob/e195e6bad6706230a4b5fd4b5cc13de1f16f25cc/llvm/lib/IR/Globals.cpp#L141) - [llvm/lib/Linker/IRMover.cpp:660](https://github.com/llvm/llvm-project/blob/e195e6bad6706230a4b5fd4b5cc13de1f16f25cc/llvm/lib/Linker/IRMover.cpp#L660) - [llvm/lib/Linker/LinkModules.cpp:361](https://github.com/llvm/llvm-project/blob/e195e6bad6706230a4b5fd4b5cc13de1f16f25cc/llvm/lib/Linker/LinkModules.cpp#L361) - [llvm/lib/Linker/LinkModules.cpp:362](https://github.com/llvm/llvm-project/blob/e195e6bad6706230a4b5fd4b5cc13de1f16f25cc/llvm/lib/Linker/LinkModules.cpp#L362) - [llvm/lib/Transforms/IPO/MergeFunctions.cpp:782](https://github.com/llvm/llvm-project/blob/e195e6bad6706230a4b5fd4b5cc13de1f16f25cc/llvm/lib/Transforms/IPO/MergeFunctions.cpp#L782) - [llvm/lib/Transforms/IPO/MergeFunctions.cpp:840](https://github.com/llvm/llvm-project/blob/e195e6bad6706230a4b5fd4b5cc13de1f16f25cc/llvm/lib/Transforms/IPO/MergeFunctions.cpp#L840) - [llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp:1813](https://github.com/llvm/llvm-project/blob/e195e6bad6706230a4b5fd4b5cc13de1f16f25cc/llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp#L1813) - [llvm/tools/llvm-reduce/deltas/ReduceGlobalObjects.cpp:27](https://github.com/llvm/llvm-project/blob/e195e6bad6706230a4b5fd4b5cc13de1f16f25cc/llvm/tools/llvm-reduce/deltas/ReduceGlobalObjects.cpp#L27) Differential Revision: https://reviews.llvm.org/D142708
2023-01-31 15:02:46 +00:00
void GlobalObject::setAlignment(Align Align) {
assert(Align <= MaximumAlignment &&
"Alignment is greater than MaximumAlignment!");
unsigned AlignmentData = encode(Align);
unsigned OldData = getGlobalValueSubClassData();
setGlobalValueSubClassData((OldData & ~AlignmentMask) | AlignmentData);
assert(getAlign() && *getAlign() == Align &&
"Alignment representation error!");
}
void GlobalObject::copyAttributesFrom(const GlobalObject *Src) {
GlobalValue::copyAttributesFrom(Src);
setAlignment(Src->getAlign());
setSection(Src->getSection());
}
std::string GlobalValue::getGlobalIdentifier(StringRef Name,
GlobalValue::LinkageTypes Linkage,
StringRef FileName) {
// Value names may be prefixed with a binary '1' to indicate
// that the backend should not modify the symbols due to any platform
// naming convention. Do not include that '1' in the PGO profile name.
Name.consume_front("\1");
Reland the reland "[PGO][GlobalValue][LTO]In GlobalValues::getGlobalIdentifier, use semicolon as delimiter for local-linkage varibles. " (#75954) Simplify the compiler-rt test to make it more general for different platforms, and use `*DAG` matchers for lines that may be emitted out-of-order. - The compiler-rt test passed on a Windows machine. Previously name matchers don't work for MSVC mangling (https://lab.llvm.org/buildbot/#/builders/127/builds/59907) - `*DAG` matchers fixed the error in https://lab.llvm.org/buildbot/#/builders/94/builds/17924 This is the second reland and fixed errors caught in first reland (https://github.com/llvm/llvm-project/pull/75860) **Original commit message** Commit fe05193 (phab D156569), IRPGO names uses format `[<filepath>;]<linkage-name>` while prior format is `[<filepath>:<mangled-name>`. The format change would break the use case demonstrated in (updated) `llvm/test/Transforms/PGOProfile/thinlto_indirect_call_promotion.ll` and `compiler-rt/test/profile/instrprof-thinlto-indirect-call-promotion.cpp` This patch changes `GlobalValues::getGlobalIdentifer` to use the semicolon. To elaborate on the scenario how things break without this PR 1. IRPGO raw profiles stores (compressed) IRPGO names of functions in one section, and per-function profile data in another section. The [NameRef](https://github.com/llvm/llvm-project/blob/fc715e4cd942612a091097339841733757b53824/compiler-rt/include/profile/InstrProfData.inc#L72) field in per-function profile data is the MD5 hash of IRPGO names. 2. When raw profiles are converted to indexed format profiles, the profiled address is [mapped](https://github.com/llvm/llvm-project/blob/fc715e4cd942612a091097339841733757b53824/llvm/lib/ProfileData/InstrProf.cpp#L876-L885) to the MD5 hash of the callee. 3. In `pgo-instr-use` thin-lto prelink pipeline, MD5 hash of IRPGO names will be [annotated](https://github.com/llvm/llvm-project/blob/fc715e4cd942612a091097339841733757b53824/llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp#L1707) as value profiles, and used to import indirect-call-prom candidates. If the annotated MD5 hash is computed from the new format while import uses the prior format, the callee cannot be imported. * `compiler-rt/test/profile/instrprof-thinlto-indirect-call-promotion.cpp` is added to have an end-to-end test. * `llvm/test/Transforms/PGOProfile/thinlto_indirect_call_promotion.ll` is updated to have better test coverage from another aspect (as runtime tests are more sensitive to the environment and may be skipped by some contributors)
2023-12-19 12:25:56 -08:00
std::string GlobalName;
if (llvm::GlobalValue::isLocalLinkage(Linkage)) {
// For local symbols, prepend the main file name to distinguish them.
// Do not include the full path in the file name since there's no guarantee
// that it will stay the same, e.g., if the files are checked out from
// version control in different locations.
if (FileName.empty())
Reland the reland "[PGO][GlobalValue][LTO]In GlobalValues::getGlobalIdentifier, use semicolon as delimiter for local-linkage varibles. " (#75954) Simplify the compiler-rt test to make it more general for different platforms, and use `*DAG` matchers for lines that may be emitted out-of-order. - The compiler-rt test passed on a Windows machine. Previously name matchers don't work for MSVC mangling (https://lab.llvm.org/buildbot/#/builders/127/builds/59907) - `*DAG` matchers fixed the error in https://lab.llvm.org/buildbot/#/builders/94/builds/17924 This is the second reland and fixed errors caught in first reland (https://github.com/llvm/llvm-project/pull/75860) **Original commit message** Commit fe05193 (phab D156569), IRPGO names uses format `[<filepath>;]<linkage-name>` while prior format is `[<filepath>:<mangled-name>`. The format change would break the use case demonstrated in (updated) `llvm/test/Transforms/PGOProfile/thinlto_indirect_call_promotion.ll` and `compiler-rt/test/profile/instrprof-thinlto-indirect-call-promotion.cpp` This patch changes `GlobalValues::getGlobalIdentifer` to use the semicolon. To elaborate on the scenario how things break without this PR 1. IRPGO raw profiles stores (compressed) IRPGO names of functions in one section, and per-function profile data in another section. The [NameRef](https://github.com/llvm/llvm-project/blob/fc715e4cd942612a091097339841733757b53824/compiler-rt/include/profile/InstrProfData.inc#L72) field in per-function profile data is the MD5 hash of IRPGO names. 2. When raw profiles are converted to indexed format profiles, the profiled address is [mapped](https://github.com/llvm/llvm-project/blob/fc715e4cd942612a091097339841733757b53824/llvm/lib/ProfileData/InstrProf.cpp#L876-L885) to the MD5 hash of the callee. 3. In `pgo-instr-use` thin-lto prelink pipeline, MD5 hash of IRPGO names will be [annotated](https://github.com/llvm/llvm-project/blob/fc715e4cd942612a091097339841733757b53824/llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp#L1707) as value profiles, and used to import indirect-call-prom candidates. If the annotated MD5 hash is computed from the new format while import uses the prior format, the callee cannot be imported. * `compiler-rt/test/profile/instrprof-thinlto-indirect-call-promotion.cpp` is added to have an end-to-end test. * `llvm/test/Transforms/PGOProfile/thinlto_indirect_call_promotion.ll` is updated to have better test coverage from another aspect (as runtime tests are more sensitive to the environment and may be skipped by some contributors)
2023-12-19 12:25:56 -08:00
GlobalName += "<unknown>";
else
Reland the reland "[PGO][GlobalValue][LTO]In GlobalValues::getGlobalIdentifier, use semicolon as delimiter for local-linkage varibles. " (#75954) Simplify the compiler-rt test to make it more general for different platforms, and use `*DAG` matchers for lines that may be emitted out-of-order. - The compiler-rt test passed on a Windows machine. Previously name matchers don't work for MSVC mangling (https://lab.llvm.org/buildbot/#/builders/127/builds/59907) - `*DAG` matchers fixed the error in https://lab.llvm.org/buildbot/#/builders/94/builds/17924 This is the second reland and fixed errors caught in first reland (https://github.com/llvm/llvm-project/pull/75860) **Original commit message** Commit fe05193 (phab D156569), IRPGO names uses format `[<filepath>;]<linkage-name>` while prior format is `[<filepath>:<mangled-name>`. The format change would break the use case demonstrated in (updated) `llvm/test/Transforms/PGOProfile/thinlto_indirect_call_promotion.ll` and `compiler-rt/test/profile/instrprof-thinlto-indirect-call-promotion.cpp` This patch changes `GlobalValues::getGlobalIdentifer` to use the semicolon. To elaborate on the scenario how things break without this PR 1. IRPGO raw profiles stores (compressed) IRPGO names of functions in one section, and per-function profile data in another section. The [NameRef](https://github.com/llvm/llvm-project/blob/fc715e4cd942612a091097339841733757b53824/compiler-rt/include/profile/InstrProfData.inc#L72) field in per-function profile data is the MD5 hash of IRPGO names. 2. When raw profiles are converted to indexed format profiles, the profiled address is [mapped](https://github.com/llvm/llvm-project/blob/fc715e4cd942612a091097339841733757b53824/llvm/lib/ProfileData/InstrProf.cpp#L876-L885) to the MD5 hash of the callee. 3. In `pgo-instr-use` thin-lto prelink pipeline, MD5 hash of IRPGO names will be [annotated](https://github.com/llvm/llvm-project/blob/fc715e4cd942612a091097339841733757b53824/llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp#L1707) as value profiles, and used to import indirect-call-prom candidates. If the annotated MD5 hash is computed from the new format while import uses the prior format, the callee cannot be imported. * `compiler-rt/test/profile/instrprof-thinlto-indirect-call-promotion.cpp` is added to have an end-to-end test. * `llvm/test/Transforms/PGOProfile/thinlto_indirect_call_promotion.ll` is updated to have better test coverage from another aspect (as runtime tests are more sensitive to the environment and may be skipped by some contributors)
2023-12-19 12:25:56 -08:00
GlobalName += FileName;
GlobalName += GlobalIdentifierDelimiter;
}
Reland the reland "[PGO][GlobalValue][LTO]In GlobalValues::getGlobalIdentifier, use semicolon as delimiter for local-linkage varibles. " (#75954) Simplify the compiler-rt test to make it more general for different platforms, and use `*DAG` matchers for lines that may be emitted out-of-order. - The compiler-rt test passed on a Windows machine. Previously name matchers don't work for MSVC mangling (https://lab.llvm.org/buildbot/#/builders/127/builds/59907) - `*DAG` matchers fixed the error in https://lab.llvm.org/buildbot/#/builders/94/builds/17924 This is the second reland and fixed errors caught in first reland (https://github.com/llvm/llvm-project/pull/75860) **Original commit message** Commit fe05193 (phab D156569), IRPGO names uses format `[<filepath>;]<linkage-name>` while prior format is `[<filepath>:<mangled-name>`. The format change would break the use case demonstrated in (updated) `llvm/test/Transforms/PGOProfile/thinlto_indirect_call_promotion.ll` and `compiler-rt/test/profile/instrprof-thinlto-indirect-call-promotion.cpp` This patch changes `GlobalValues::getGlobalIdentifer` to use the semicolon. To elaborate on the scenario how things break without this PR 1. IRPGO raw profiles stores (compressed) IRPGO names of functions in one section, and per-function profile data in another section. The [NameRef](https://github.com/llvm/llvm-project/blob/fc715e4cd942612a091097339841733757b53824/compiler-rt/include/profile/InstrProfData.inc#L72) field in per-function profile data is the MD5 hash of IRPGO names. 2. When raw profiles are converted to indexed format profiles, the profiled address is [mapped](https://github.com/llvm/llvm-project/blob/fc715e4cd942612a091097339841733757b53824/llvm/lib/ProfileData/InstrProf.cpp#L876-L885) to the MD5 hash of the callee. 3. In `pgo-instr-use` thin-lto prelink pipeline, MD5 hash of IRPGO names will be [annotated](https://github.com/llvm/llvm-project/blob/fc715e4cd942612a091097339841733757b53824/llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp#L1707) as value profiles, and used to import indirect-call-prom candidates. If the annotated MD5 hash is computed from the new format while import uses the prior format, the callee cannot be imported. * `compiler-rt/test/profile/instrprof-thinlto-indirect-call-promotion.cpp` is added to have an end-to-end test. * `llvm/test/Transforms/PGOProfile/thinlto_indirect_call_promotion.ll` is updated to have better test coverage from another aspect (as runtime tests are more sensitive to the environment and may be skipped by some contributors)
2023-12-19 12:25:56 -08:00
GlobalName += Name;
return GlobalName;
}
std::string GlobalValue::getGlobalIdentifier() const {
return getGlobalIdentifier(getName(), getLinkage(),
getParent()->getSourceFileName());
}
StringRef GlobalValue::getSection() const {
if (auto *GA = dyn_cast<GlobalAlias>(this)) {
// In general we cannot compute this at the IR level, but we try.
if (const GlobalObject *GO = GA->getAliaseeObject())
return GO->getSection();
return "";
}
return cast<GlobalObject>(this)->getSection();
}
const Comdat *GlobalValue::getComdat() const {
if (auto *GA = dyn_cast<GlobalAlias>(this)) {
// In general we cannot compute this at the IR level, but we try.
if (const GlobalObject *GO = GA->getAliaseeObject())
return const_cast<GlobalObject *>(GO)->getComdat();
return nullptr;
}
// ifunc and its resolver are separate things so don't use resolver comdat.
if (isa<GlobalIFunc>(this))
return nullptr;
return cast<GlobalObject>(this)->getComdat();
}
void GlobalObject::setComdat(Comdat *C) {
if (ObjComdat)
ObjComdat->removeUser(this);
ObjComdat = C;
if (C)
C->addUser(this);
}
StringRef GlobalValue::getPartition() const {
if (!hasPartition())
return "";
return getContext().pImpl->GlobalValuePartitions[this];
}
void GlobalValue::setPartition(StringRef S) {
// Do nothing if we're clearing the partition and it is already empty.
if (!hasPartition() && S.empty())
return;
// Get or create a stable partition name string and put it in the table in the
// context.
if (!S.empty())
S = getContext().pImpl->Saver.save(S);
getContext().pImpl->GlobalValuePartitions[this] = S;
// Update the HasPartition field. Setting the partition to the empty string
// means this global no longer has a partition.
HasPartition = !S.empty();
}
using SanitizerMetadata = GlobalValue::SanitizerMetadata;
const SanitizerMetadata &GlobalValue::getSanitizerMetadata() const {
assert(hasSanitizerMetadata());
assert(getContext().pImpl->GlobalValueSanitizerMetadata.count(this));
return getContext().pImpl->GlobalValueSanitizerMetadata[this];
}
void GlobalValue::setSanitizerMetadata(SanitizerMetadata Meta) {
getContext().pImpl->GlobalValueSanitizerMetadata[this] = Meta;
HasSanitizerMetadata = true;
}
void GlobalValue::removeSanitizerMetadata() {
DenseMap<const GlobalValue *, SanitizerMetadata> &MetadataMap =
getContext().pImpl->GlobalValueSanitizerMetadata;
MetadataMap.erase(this);
HasSanitizerMetadata = false;
}
void GlobalValue::setNoSanitizeMetadata() {
SanitizerMetadata Meta;
Meta.NoAddress = true;
Meta.NoHWAddress = true;
setSanitizerMetadata(Meta);
}
StringRef GlobalObject::getSectionImpl() const {
assert(hasSection());
return getContext().pImpl->GlobalObjectSections[this];
}
void GlobalObject::setSection(StringRef S) {
// Do nothing if we're clearing the section and it is already empty.
if (!hasSection() && S.empty())
return;
// Get or create a stable section name string and put it in the table in the
// context.
if (!S.empty())
S = getContext().pImpl->Saver.save(S);
getContext().pImpl->GlobalObjectSections[this] = S;
// Update the HasSectionHashEntryBit. Setting the section to the empty string
// means this global no longer has a section.
setGlobalObjectFlag(HasSectionHashEntryBit, !S.empty());
}
void GlobalObject::setSectionPrefix(StringRef Prefix) {
MDBuilder MDB(getContext());
setMetadata(LLVMContext::MD_section_prefix,
MDB.createGlobalObjectSectionPrefix(Prefix));
}
std::optional<StringRef> GlobalObject::getSectionPrefix() const {
if (MDNode *MD = getMetadata(LLVMContext::MD_section_prefix)) {
[[maybe_unused]] StringRef MDName =
cast<MDString>(MD->getOperand(0))->getString();
assert((MDName == "section_prefix" ||
(isa<Function>(this) && MDName == "function_section_prefix")) &&
"Metadata not match");
return cast<MDString>(MD->getOperand(1))->getString();
}
return std::nullopt;
}
bool GlobalValue::isNobuiltinFnDef() const {
const Function *F = dyn_cast<Function>(this);
if (!F || F->empty())
return false;
return F->hasFnAttribute(Attribute::NoBuiltin);
}
bool GlobalValue::isDeclaration() const {
2011-07-14 18:12:44 +00:00
// Globals are definitions if they have an initializer.
if (const GlobalVariable *GV = dyn_cast<GlobalVariable>(this))
return GV->getNumOperands() == 0;
2011-07-14 18:12:44 +00:00
// Functions are definitions if they have a body.
if (const Function *F = dyn_cast<Function>(this))
return F->empty() && !F->isMaterializable();
2011-07-14 18:12:44 +00:00
// Aliases and ifuncs are always definitions.
2021-10-20 10:29:47 -07:00
assert(isa<GlobalAlias>(this) || isa<GlobalIFunc>(this));
return false;
}
bool GlobalObject::canIncreaseAlignment() const {
// Firstly, can only increase the alignment of a global if it
// is a strong definition.
if (!isStrongDefinitionForLinker())
return false;
// It also has to either not have a section defined, or, not have
// alignment specified. (If it is assigned a section, the global
// could be densely packed with other objects in the section, and
// increasing the alignment could cause padding issues.)
if (hasSection() && getAlign())
return false;
// On ELF platforms, we're further restricted in that we can't
// increase the alignment of any variable which might be emitted
// into a shared library, and which is exported. If the main
// executable accesses a variable found in a shared-lib, the main
// exe actually allocates memory for and exports the symbol ITSELF,
// overriding the symbol found in the library. That is, at link
// time, the observed alignment of the variable is copied into the
// executable binary. (A COPY relocation is also generated, to copy
// the initial data from the shadowed variable in the shared-lib
// into the location in the main binary, before running code.)
//
// And thus, even though you might think you are defining the
// global, and allocating the memory for the global in your object
// file, and thus should be able to set the alignment arbitrarily,
// that's not actually true. Doing so can cause an ABI breakage; an
// executable might have already been built with the previous
// alignment of the variable, and then assuming an increased
// alignment will be incorrect.
// Conservatively assume ELF if there's no parent pointer.
bool isELF =
(!Parent || Triple(Parent->getTargetTriple()).isOSBinFormatELF());
if (isELF && !isDSOLocal())
return false;
// GV with toc-data attribute is defined in a TOC entry. To mitigate TOC
// overflow, the alignment of such symbol should not be increased. Otherwise,
// padding is needed thus more TOC entries are wasted.
bool isXCOFF =
(!Parent || Triple(Parent->getTargetTriple()).isOSBinFormatXCOFF());
if (isXCOFF)
if (const GlobalVariable *GV = dyn_cast<GlobalVariable>(this))
if (GV->hasAttribute("toc-data"))
return false;
return true;
}
template <typename Operation>
2021-10-20 10:29:47 -07:00
static const GlobalObject *
findBaseObject(const Constant *C, DenseSet<const GlobalAlias *> &Aliases,
const Operation &Op) {
if (auto *GO = dyn_cast<GlobalObject>(C)) {
Op(*GO);
return GO;
}
if (auto *GA = dyn_cast<GlobalAlias>(C)) {
Op(*GA);
2021-10-20 10:29:47 -07:00
if (Aliases.insert(GA).second)
return findBaseObject(GA->getOperand(0), Aliases, Op);
}
2021-10-20 10:29:47 -07:00
if (auto *CE = dyn_cast<ConstantExpr>(C)) {
switch (CE->getOpcode()) {
case Instruction::Add: {
auto *LHS = findBaseObject(CE->getOperand(0), Aliases, Op);
auto *RHS = findBaseObject(CE->getOperand(1), Aliases, Op);
2021-10-20 10:29:47 -07:00
if (LHS && RHS)
return nullptr;
return LHS ? LHS : RHS;
}
case Instruction::Sub: {
if (findBaseObject(CE->getOperand(1), Aliases, Op))
2021-10-20 10:29:47 -07:00
return nullptr;
return findBaseObject(CE->getOperand(0), Aliases, Op);
2021-10-20 10:29:47 -07:00
}
case Instruction::IntToPtr:
case Instruction::PtrToInt:
case Instruction::BitCast:
case Instruction::GetElementPtr:
return findBaseObject(CE->getOperand(0), Aliases, Op);
2021-10-20 10:29:47 -07:00
default:
break;
}
}
return nullptr;
}
2021-10-20 10:29:47 -07:00
const GlobalObject *GlobalValue::getAliaseeObject() const {
DenseSet<const GlobalAlias *> Aliases;
return findBaseObject(this, Aliases, [](const GlobalValue &) {});
2021-10-20 10:29:47 -07:00
}
bool GlobalValue::isAbsoluteSymbolRef() const {
auto *GO = dyn_cast<GlobalObject>(this);
if (!GO)
return false;
return GO->getMetadata(LLVMContext::MD_absolute_symbol);
}
std::optional<ConstantRange> GlobalValue::getAbsoluteSymbolRange() const {
auto *GO = dyn_cast<GlobalObject>(this);
if (!GO)
return std::nullopt;
MDNode *MD = GO->getMetadata(LLVMContext::MD_absolute_symbol);
if (!MD)
return std::nullopt;
return getConstantRangeFromMetadata(*MD);
}
bool GlobalValue::canBeOmittedFromSymbolTable() const {
if (!hasLinkOnceODRLinkage())
return false;
// We assume that anyone who sets global unnamed_addr on a non-constant
// knows what they're doing.
if (hasGlobalUnnamedAddr())
return true;
// If it is a non constant variable, it needs to be uniqued across shared
// objects.
if (auto *Var = dyn_cast<GlobalVariable>(this))
if (!Var->isConstant())
return false;
return hasAtLeastLocalUnnamedAddr();
}
//===----------------------------------------------------------------------===//
// GlobalVariable Implementation
//===----------------------------------------------------------------------===//
GlobalVariable::GlobalVariable(Type *Ty, bool constant, LinkageTypes Link,
Constant *InitVal, const Twine &Name,
ThreadLocalMode TLMode, unsigned AddressSpace,
bool isExternallyInitialized)
Don't rely on undefined behavior to store how a `User` object's allocation is laid out (#105714) In `User::operator new` a single allocation is created to store the `User` object itself, "intrusive" operands or a pointer for "hung off" operands, and the descriptor. After allocation, details about the layout (number of operands, how the operands are stored, if there is a descriptor) are stored in the `User` object by settings its fields. The `Value` and `User` constructors are then very careful not to initialize these fields so that the values set during allocation can be subsequently read. However, when the `User` object is returned from `operator new` [its value is technically "indeterminate" and so reading a field without first initializing it is undefined behavior (and will be erroneous in C++26)](https://en.cppreference.com/w/cpp/language/default_initialization#Indeterminate_and_erroneous_values). We discovered this issue when trying to build LLVM using MSVC's [`/sdl` flag](https://learn.microsoft.com/en-us/cpp/build/reference/sdl-enable-additional-security-checks?view=msvc-170) which clears class fields after allocation (the docs say that this feature shouldn't be turned on for custom allocators and should only clear pointers, but that doesn't seem to match the implementation). MSVC's behavior both with and without the `/sdl` flag is standards conforming since a program is supposed to initialize storage before reading from it, thus the compiler implementation changing any values will never be observed in a well-formed program. The standard also provides no provisions for making storage bytes not indeterminate by setting them during allocation or `operator new`. The fix for this is to create a set of types that encode the layout and provide these to both `operator new` and the constructor: * The `AllocMarker` types are used to select which `operator new` to use. * `AllocMarker` can then be implicitly converted to a `AllocInfo` which tells the constructor how the type was laid out.
2024-09-11 11:34:26 -07:00
: GlobalObject(Ty, Value::GlobalVariableVal, AllocMarker, Link, Name,
AddressSpace),
isConstantGlobal(constant),
isExternallyInitializedConstant(isExternallyInitialized) {
assert(!Ty->isFunctionTy() && PointerType::isValidElementType(Ty) &&
"invalid type for global variable");
setThreadLocalMode(TLMode);
if (InitVal) {
assert(InitVal->getType() == Ty &&
"Initializer should be the same type as the GlobalVariable!");
Op<0>() = InitVal;
Don't rely on undefined behavior to store how a `User` object's allocation is laid out (#105714) In `User::operator new` a single allocation is created to store the `User` object itself, "intrusive" operands or a pointer for "hung off" operands, and the descriptor. After allocation, details about the layout (number of operands, how the operands are stored, if there is a descriptor) are stored in the `User` object by settings its fields. The `Value` and `User` constructors are then very careful not to initialize these fields so that the values set during allocation can be subsequently read. However, when the `User` object is returned from `operator new` [its value is technically "indeterminate" and so reading a field without first initializing it is undefined behavior (and will be erroneous in C++26)](https://en.cppreference.com/w/cpp/language/default_initialization#Indeterminate_and_erroneous_values). We discovered this issue when trying to build LLVM using MSVC's [`/sdl` flag](https://learn.microsoft.com/en-us/cpp/build/reference/sdl-enable-additional-security-checks?view=msvc-170) which clears class fields after allocation (the docs say that this feature shouldn't be turned on for custom allocators and should only clear pointers, but that doesn't seem to match the implementation). MSVC's behavior both with and without the `/sdl` flag is standards conforming since a program is supposed to initialize storage before reading from it, thus the compiler implementation changing any values will never be observed in a well-formed program. The standard also provides no provisions for making storage bytes not indeterminate by setting them during allocation or `operator new`. The fix for this is to create a set of types that encode the layout and provide these to both `operator new` and the constructor: * The `AllocMarker` types are used to select which `operator new` to use. * `AllocMarker` can then be implicitly converted to a `AllocInfo` which tells the constructor how the type was laid out.
2024-09-11 11:34:26 -07:00
} else {
setGlobalVariableNumOperands(0);
}
}
GlobalVariable::GlobalVariable(Module &M, Type *Ty, bool constant,
LinkageTypes Link, Constant *InitVal,
const Twine &Name, GlobalVariable *Before,
ThreadLocalMode TLMode,
std::optional<unsigned> AddressSpace,
bool isExternallyInitialized)
: GlobalVariable(Ty, constant, Link, InitVal, Name, TLMode,
AddressSpace
? *AddressSpace
: M.getDataLayout().getDefaultGlobalsAddressSpace(),
isExternallyInitialized) {
if (Before)
Before->getParent()->insertGlobalVariable(Before->getIterator(), this);
else
M.insertGlobalVariable(this);
}
void GlobalVariable::removeFromParent() {
getParent()->removeGlobalVariable(this);
}
void GlobalVariable::eraseFromParent() {
getParent()->eraseGlobalVariable(this);
}
void GlobalVariable::setInitializer(Constant *InitVal) {
if (!InitVal) {
if (hasInitializer()) {
// Note, the num operands is used to compute the offset of the operand, so
// the order here matters. Clearing the operand then clearing the num
// operands ensures we have the correct offset to the operand.
Op<0>().set(nullptr);
setGlobalVariableNumOperands(0);
}
} else {
assert(InitVal->getType() == getValueType() &&
"Initializer type must match GlobalVariable type");
// Note, the num operands is used to compute the offset of the operand, so
// the order here matters. We need to set num operands to 1 first so that
// we get the correct offset to the first operand when we set it.
if (!hasInitializer())
setGlobalVariableNumOperands(1);
Op<0>().set(InitVal);
}
}
void GlobalVariable::replaceInitializer(Constant *InitVal) {
assert(InitVal && "Can't compute type of null initializer");
ValueType = InitVal->getType();
setInitializer(InitVal);
}
/// Copy all additional attributes (those not needed to create a GlobalVariable)
/// from the GlobalVariable Src to this one.
void GlobalVariable::copyAttributesFrom(const GlobalVariable *Src) {
GlobalObject::copyAttributesFrom(Src);
setExternallyInitialized(Src->isExternallyInitialized());
setAttributes(Src->getAttributes());
if (auto CM = Src->getCodeModel())
setCodeModel(*CM);
}
void GlobalVariable::dropAllReferences() {
User::dropAllReferences();
clearMetadata();
}
void GlobalVariable::setCodeModel(CodeModel::Model CM) {
unsigned CodeModelData = static_cast<unsigned>(CM) + 1;
unsigned OldData = getGlobalValueSubClassData();
unsigned NewData = (OldData & ~(CodeModelMask << CodeModelShift)) |
(CodeModelData << CodeModelShift);
setGlobalValueSubClassData(NewData);
assert(getCodeModel() == CM && "Code model representation error!");
}
//===----------------------------------------------------------------------===//
// GlobalAlias Implementation
//===----------------------------------------------------------------------===//
GlobalAlias::GlobalAlias(Type *Ty, unsigned AddressSpace, LinkageTypes Link,
const Twine &Name, Constant *Aliasee,
Module *ParentModule)
Don't rely on undefined behavior to store how a `User` object's allocation is laid out (#105714) In `User::operator new` a single allocation is created to store the `User` object itself, "intrusive" operands or a pointer for "hung off" operands, and the descriptor. After allocation, details about the layout (number of operands, how the operands are stored, if there is a descriptor) are stored in the `User` object by settings its fields. The `Value` and `User` constructors are then very careful not to initialize these fields so that the values set during allocation can be subsequently read. However, when the `User` object is returned from `operator new` [its value is technically "indeterminate" and so reading a field without first initializing it is undefined behavior (and will be erroneous in C++26)](https://en.cppreference.com/w/cpp/language/default_initialization#Indeterminate_and_erroneous_values). We discovered this issue when trying to build LLVM using MSVC's [`/sdl` flag](https://learn.microsoft.com/en-us/cpp/build/reference/sdl-enable-additional-security-checks?view=msvc-170) which clears class fields after allocation (the docs say that this feature shouldn't be turned on for custom allocators and should only clear pointers, but that doesn't seem to match the implementation). MSVC's behavior both with and without the `/sdl` flag is standards conforming since a program is supposed to initialize storage before reading from it, thus the compiler implementation changing any values will never be observed in a well-formed program. The standard also provides no provisions for making storage bytes not indeterminate by setting them during allocation or `operator new`. The fix for this is to create a set of types that encode the layout and provide these to both `operator new` and the constructor: * The `AllocMarker` types are used to select which `operator new` to use. * `AllocMarker` can then be implicitly converted to a `AllocInfo` which tells the constructor how the type was laid out.
2024-09-11 11:34:26 -07:00
: GlobalValue(Ty, Value::GlobalAliasVal, AllocMarker, Link, Name,
2021-10-20 10:29:47 -07:00
AddressSpace) {
setAliasee(Aliasee);
if (ParentModule)
ParentModule->insertAlias(this);
}
GlobalAlias *GlobalAlias::create(Type *Ty, unsigned AddressSpace,
LinkageTypes Link, const Twine &Name,
Constant *Aliasee, Module *ParentModule) {
return new GlobalAlias(Ty, AddressSpace, Link, Name, Aliasee, ParentModule);
}
GlobalAlias *GlobalAlias::create(Type *Ty, unsigned AddressSpace,
LinkageTypes Linkage, const Twine &Name,
Module *Parent) {
return create(Ty, AddressSpace, Linkage, Name, nullptr, Parent);
}
GlobalAlias *GlobalAlias::create(Type *Ty, unsigned AddressSpace,
LinkageTypes Linkage, const Twine &Name,
GlobalValue *Aliasee) {
return create(Ty, AddressSpace, Linkage, Name, Aliasee, Aliasee->getParent());
}
GlobalAlias *GlobalAlias::create(LinkageTypes Link, const Twine &Name,
GlobalValue *Aliasee) {
return create(Aliasee->getValueType(), Aliasee->getAddressSpace(), Link, Name,
Aliasee);
}
GlobalAlias *GlobalAlias::create(const Twine &Name, GlobalValue *Aliasee) {
return create(Aliasee->getLinkage(), Name, Aliasee);
}
void GlobalAlias::removeFromParent() { getParent()->removeAlias(this); }
void GlobalAlias::eraseFromParent() { getParent()->eraseAlias(this); }
void GlobalAlias::setAliasee(Constant *Aliasee) {
assert((!Aliasee || Aliasee->getType() == getType()) &&
"Alias and aliasee types should match!");
2021-10-20 10:29:47 -07:00
Op<0>().set(Aliasee);
}
const GlobalObject *GlobalAlias::getAliaseeObject() const {
DenseSet<const GlobalAlias *> Aliases;
return findBaseObject(getOperand(0), Aliases, [](const GlobalValue &) {});
}
//===----------------------------------------------------------------------===//
// GlobalIFunc Implementation
//===----------------------------------------------------------------------===//
GlobalIFunc::GlobalIFunc(Type *Ty, unsigned AddressSpace, LinkageTypes Link,
const Twine &Name, Constant *Resolver,
Module *ParentModule)
Don't rely on undefined behavior to store how a `User` object's allocation is laid out (#105714) In `User::operator new` a single allocation is created to store the `User` object itself, "intrusive" operands or a pointer for "hung off" operands, and the descriptor. After allocation, details about the layout (number of operands, how the operands are stored, if there is a descriptor) are stored in the `User` object by settings its fields. The `Value` and `User` constructors are then very careful not to initialize these fields so that the values set during allocation can be subsequently read. However, when the `User` object is returned from `operator new` [its value is technically "indeterminate" and so reading a field without first initializing it is undefined behavior (and will be erroneous in C++26)](https://en.cppreference.com/w/cpp/language/default_initialization#Indeterminate_and_erroneous_values). We discovered this issue when trying to build LLVM using MSVC's [`/sdl` flag](https://learn.microsoft.com/en-us/cpp/build/reference/sdl-enable-additional-security-checks?view=msvc-170) which clears class fields after allocation (the docs say that this feature shouldn't be turned on for custom allocators and should only clear pointers, but that doesn't seem to match the implementation). MSVC's behavior both with and without the `/sdl` flag is standards conforming since a program is supposed to initialize storage before reading from it, thus the compiler implementation changing any values will never be observed in a well-formed program. The standard also provides no provisions for making storage bytes not indeterminate by setting them during allocation or `operator new`. The fix for this is to create a set of types that encode the layout and provide these to both `operator new` and the constructor: * The `AllocMarker` types are used to select which `operator new` to use. * `AllocMarker` can then be implicitly converted to a `AllocInfo` which tells the constructor how the type was laid out.
2024-09-11 11:34:26 -07:00
: GlobalObject(Ty, Value::GlobalIFuncVal, AllocMarker, Link, Name,
2021-10-20 10:29:47 -07:00
AddressSpace) {
setResolver(Resolver);
if (ParentModule)
ParentModule->insertIFunc(this);
}
GlobalIFunc *GlobalIFunc::create(Type *Ty, unsigned AddressSpace,
LinkageTypes Link, const Twine &Name,
Constant *Resolver, Module *ParentModule) {
return new GlobalIFunc(Ty, AddressSpace, Link, Name, Resolver, ParentModule);
}
void GlobalIFunc::removeFromParent() { getParent()->removeIFunc(this); }
void GlobalIFunc::eraseFromParent() { getParent()->eraseIFunc(this); }
const Function *GlobalIFunc::getResolverFunction() const {
return dyn_cast<Function>(getResolver()->stripPointerCastsAndAliases());
}
void GlobalIFunc::applyAlongResolverPath(
function_ref<void(const GlobalValue &)> Op) const {
DenseSet<const GlobalAlias *> Aliases;
findBaseObject(getResolver(), Aliases, Op);
}