2003-09-30 18:37:50 +00:00
|
|
|
//===-- llvm/GlobalValue.h - Class to represent a global value --*- C++ -*-===//
|
2005-04-21 20:19:05 +00:00
|
|
|
//
|
2003-10-20 20:19:47 +00:00
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
2007-12-29 19:59:42 +00:00
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
2005-04-21 20:19:05 +00:00
|
|
|
//
|
2003-10-20 20:19:47 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
2001-10-03 14:53:21 +00:00
|
|
|
//
|
|
|
|
// This file is a common base class of all globally definable objects. As such,
|
2007-04-30 19:14:56 +00:00
|
|
|
// it is subclassed by GlobalVariable, GlobalAlias and by Function. This is
|
|
|
|
// used because you can do certain things with these global objects that you
|
|
|
|
// can't do to anything else. For example, use the address of one as a
|
|
|
|
// constant.
|
2001-10-03 14:53:21 +00:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2013-01-10 00:45:19 +00:00
|
|
|
#ifndef LLVM_IR_GLOBALVALUE_H
|
|
|
|
#define LLVM_IR_GLOBALVALUE_H
|
2001-10-03 14:53:21 +00:00
|
|
|
|
2013-01-02 11:36:10 +00:00
|
|
|
#include "llvm/IR/Constant.h"
|
2013-05-01 15:04:18 +00:00
|
|
|
#include "llvm/IR/DerivedTypes.h"
|
2003-11-11 22:41:34 +00:00
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
|
2001-10-03 14:53:21 +00:00
|
|
|
class PointerType;
|
2002-04-28 04:45:05 +00:00
|
|
|
class Module;
|
2001-10-03 14:53:21 +00:00
|
|
|
|
2004-07-17 23:28:28 +00:00
|
|
|
class GlobalValue : public Constant {
|
2012-09-17 07:16:40 +00:00
|
|
|
GlobalValue(const GlobalValue &) LLVM_DELETED_FUNCTION;
|
2003-04-16 20:28:45 +00:00
|
|
|
public:
|
2007-01-27 04:42:50 +00:00
|
|
|
/// @brief An enumeration for the kinds of linkage for global values.
|
2003-04-16 20:28:45 +00:00
|
|
|
enum LinkageTypes {
|
2007-04-17 04:31:29 +00:00
|
|
|
ExternalLinkage = 0,///< Externally visible function
|
2009-04-13 05:44:34 +00:00
|
|
|
AvailableExternallyLinkage, ///< Available for inspection, not emission.
|
Introduce new linkage types linkonce_odr, weak_odr, common_odr
and extern_weak_odr. These are the same as the non-odr versions,
except that they indicate that the global will only be overridden
by an *equivalent* global. In C, a function with weak linkage can
be overridden by a function which behaves completely differently.
This means that IP passes have to skip weak functions, since any
deductions made from the function definition might be wrong, since
the definition could be replaced by something completely different
at link time. This is not allowed in C++, thanks to the ODR
(One-Definition-Rule): if a function is replaced by another at
link-time, then the new function must be the same as the original
function. If a language knows that a function or other global can
only be overridden by an equivalent global, it can give it the
weak_odr linkage type, and the optimizers will understand that it
is alright to make deductions based on the function body. The
code generators on the other hand map weak and weak_odr linkage
to the same thing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66339 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-07 15:45:40 +00:00
|
|
|
LinkOnceAnyLinkage, ///< Keep one copy of function when linking (inline)
|
|
|
|
LinkOnceODRLinkage, ///< Same, but only replaced by something equivalent.
|
|
|
|
WeakAnyLinkage, ///< Keep one copy of named function when linking (weak)
|
|
|
|
WeakODRLinkage, ///< Same, but only replaced by something equivalent.
|
2007-01-27 04:42:50 +00:00
|
|
|
AppendingLinkage, ///< Special purpose, only applies to global arrays
|
2009-07-20 01:03:30 +00:00
|
|
|
InternalLinkage, ///< Rename collisions when linking (static functions).
|
|
|
|
PrivateLinkage, ///< Like Internal, but omit from symbol table.
|
|
|
|
ExternalWeakLinkage,///< ExternalWeak linkage description.
|
|
|
|
CommonLinkage ///< Tentative definitions.
|
2003-04-16 20:28:45 +00:00
|
|
|
};
|
2007-01-27 04:42:50 +00:00
|
|
|
|
|
|
|
/// @brief An enumeration for the kinds of visibility of global values.
|
2007-01-12 19:20:47 +00:00
|
|
|
enum VisibilityTypes {
|
2007-04-17 04:31:29 +00:00
|
|
|
DefaultVisibility = 0, ///< The GV is visible
|
2007-04-29 18:35:00 +00:00
|
|
|
HiddenVisibility, ///< The GV is hidden
|
|
|
|
ProtectedVisibility ///< The GV is protected
|
2007-01-12 19:20:47 +00:00
|
|
|
};
|
2007-01-27 04:42:50 +00:00
|
|
|
|
2014-01-14 15:22:47 +00:00
|
|
|
/// @brief Storage classes of global values for PE targets.
|
|
|
|
enum DLLStorageClassTypes {
|
|
|
|
DefaultStorageClass = 0,
|
|
|
|
DLLImportStorageClass = 1, ///< Function to be imported from DLL
|
|
|
|
DLLExportStorageClass = 2 ///< Function to be accessible from DLL.
|
|
|
|
};
|
|
|
|
|
2001-10-03 14:53:21 +00:00
|
|
|
protected:
|
2014-05-13 16:41:02 +00:00
|
|
|
GlobalValue(Type *Ty, ValueTy VTy, Use *Ops, unsigned NumOps,
|
|
|
|
LinkageTypes Linkage, const Twine &Name)
|
|
|
|
: Constant(Ty, VTy, Ops, NumOps), Linkage(Linkage),
|
2014-05-13 18:45:48 +00:00
|
|
|
Visibility(DefaultVisibility), UnnamedAddr(0),
|
2014-05-28 18:15:43 +00:00
|
|
|
DllStorageClass(DefaultStorageClass),
|
|
|
|
ThreadLocal(NotThreadLocal), Parent(nullptr) {
|
2009-07-25 04:41:11 +00:00
|
|
|
setName(Name);
|
2007-02-12 05:18:08 +00:00
|
|
|
}
|
2001-10-03 19:28:15 +00:00
|
|
|
|
2007-04-21 15:29:13 +00:00
|
|
|
// Note: VC++ treats enums as signed, so an extra bit is required to prevent
|
|
|
|
// Linkage and Visibility from turning into negative values.
|
|
|
|
LinkageTypes Linkage : 5; // The linkage of this global
|
2007-04-29 18:35:00 +00:00
|
|
|
unsigned Visibility : 2; // The visibility style of this global
|
2011-01-08 16:42:36 +00:00
|
|
|
unsigned UnnamedAddr : 1; // This value's address is not significant
|
2014-01-14 15:22:47 +00:00
|
|
|
unsigned DllStorageClass : 2; // DLL storage class
|
2014-05-13 18:45:48 +00:00
|
|
|
|
2014-05-28 18:15:43 +00:00
|
|
|
unsigned ThreadLocal : 3; // Is this symbol "Thread Local", if so, what is
|
|
|
|
// the desired model?
|
|
|
|
|
2014-05-13 18:45:48 +00:00
|
|
|
private:
|
|
|
|
// Give subclasses access to what otherwise would be wasted padding.
|
2014-05-28 18:15:43 +00:00
|
|
|
// (19 + 3 + 2 + 1 + 2 + 5) == 32.
|
|
|
|
unsigned SubClassData : 19;
|
2014-05-13 18:45:48 +00:00
|
|
|
protected:
|
|
|
|
unsigned getGlobalValueSubClassData() const {
|
|
|
|
return SubClassData;
|
|
|
|
}
|
|
|
|
void setGlobalValueSubClassData(unsigned V) {
|
2014-05-28 18:15:43 +00:00
|
|
|
assert(V < (1 << 19) && "It will not fit");
|
2014-05-13 18:45:48 +00:00
|
|
|
SubClassData = V;
|
|
|
|
}
|
|
|
|
|
2012-01-07 21:17:16 +00:00
|
|
|
Module *Parent; // The containing module.
|
2007-12-09 22:46:10 +00:00
|
|
|
public:
|
2014-05-28 18:15:43 +00:00
|
|
|
enum ThreadLocalMode {
|
|
|
|
NotThreadLocal = 0,
|
|
|
|
GeneralDynamicTLSModel,
|
|
|
|
LocalDynamicTLSModel,
|
|
|
|
InitialExecTLSModel,
|
|
|
|
LocalExecTLSModel
|
|
|
|
};
|
|
|
|
|
2007-12-10 02:14:30 +00:00
|
|
|
~GlobalValue() {
|
|
|
|
removeDeadConstantUsers(); // remove any dead constants using this.
|
|
|
|
}
|
|
|
|
|
2014-05-06 16:48:58 +00:00
|
|
|
unsigned getAlignment() const;
|
2007-01-12 19:20:47 +00:00
|
|
|
|
2011-01-08 16:42:36 +00:00
|
|
|
bool hasUnnamedAddr() const { return UnnamedAddr; }
|
|
|
|
void setUnnamedAddr(bool Val) { UnnamedAddr = Val; }
|
|
|
|
|
2007-08-12 08:12:35 +00:00
|
|
|
VisibilityTypes getVisibility() const { return VisibilityTypes(Visibility); }
|
2009-07-09 04:56:23 +00:00
|
|
|
bool hasDefaultVisibility() const { return Visibility == DefaultVisibility; }
|
2007-01-12 19:20:47 +00:00
|
|
|
bool hasHiddenVisibility() const { return Visibility == HiddenVisibility; }
|
2007-04-29 18:35:00 +00:00
|
|
|
bool hasProtectedVisibility() const {
|
|
|
|
return Visibility == ProtectedVisibility;
|
|
|
|
}
|
2014-05-07 23:00:22 +00:00
|
|
|
void setVisibility(VisibilityTypes V) {
|
|
|
|
assert((!hasLocalLinkage() || V == DefaultVisibility) &&
|
|
|
|
"local linkage requires default visibility");
|
|
|
|
Visibility = V;
|
|
|
|
}
|
2014-01-14 15:22:47 +00:00
|
|
|
|
2014-05-28 18:15:43 +00:00
|
|
|
/// If the value is "Thread Local", its value isn't shared by the threads.
|
|
|
|
bool isThreadLocal() const { return getThreadLocalMode() != NotThreadLocal; }
|
|
|
|
void setThreadLocal(bool Val) {
|
|
|
|
setThreadLocalMode(Val ? GeneralDynamicTLSModel : NotThreadLocal);
|
|
|
|
}
|
|
|
|
void setThreadLocalMode(ThreadLocalMode Val) {
|
|
|
|
assert(Val == NotThreadLocal || getValueID() != Value::FunctionVal);
|
|
|
|
ThreadLocal = Val;
|
|
|
|
}
|
|
|
|
ThreadLocalMode getThreadLocalMode() const {
|
|
|
|
return static_cast<ThreadLocalMode>(ThreadLocal);
|
|
|
|
}
|
|
|
|
|
2014-01-14 15:22:47 +00:00
|
|
|
DLLStorageClassTypes getDLLStorageClass() const {
|
|
|
|
return DLLStorageClassTypes(DllStorageClass);
|
|
|
|
}
|
|
|
|
bool hasDLLImportStorageClass() const {
|
|
|
|
return DllStorageClass == DLLImportStorageClass;
|
|
|
|
}
|
|
|
|
bool hasDLLExportStorageClass() const {
|
|
|
|
return DllStorageClass == DLLExportStorageClass;
|
|
|
|
}
|
|
|
|
void setDLLStorageClass(DLLStorageClassTypes C) { DllStorageClass = C; }
|
|
|
|
|
2014-06-03 02:41:57 +00:00
|
|
|
bool hasSection() const { return !StringRef(getSection()).empty(); }
|
|
|
|
// It is unfortunate that we have to use "char *" in here since this is
|
|
|
|
// always non NULL, but:
|
|
|
|
// * The C API expects a null terminated string, so we cannot use StringRef.
|
|
|
|
// * The C API expects us to own it, so we cannot use a std:string.
|
|
|
|
// * For GlobalAliases we can fail to find the section and we have to
|
|
|
|
// return "", so we cannot use a "const std::string &".
|
|
|
|
const char *getSection() const;
|
2014-02-13 18:26:41 +00:00
|
|
|
|
2014-05-07 17:04:45 +00:00
|
|
|
/// Global values are always pointers.
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134829 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-09 17:41:24 +00:00
|
|
|
inline PointerType *getType() const {
|
2013-05-01 15:04:18 +00:00
|
|
|
return cast<PointerType>(User::getType());
|
2001-10-03 14:53:21 +00:00
|
|
|
}
|
|
|
|
|
Introduce new linkage types linkonce_odr, weak_odr, common_odr
and extern_weak_odr. These are the same as the non-odr versions,
except that they indicate that the global will only be overridden
by an *equivalent* global. In C, a function with weak linkage can
be overridden by a function which behaves completely differently.
This means that IP passes have to skip weak functions, since any
deductions made from the function definition might be wrong, since
the definition could be replaced by something completely different
at link time. This is not allowed in C++, thanks to the ODR
(One-Definition-Rule): if a function is replaced by another at
link-time, then the new function must be the same as the original
function. If a language knows that a function or other global can
only be overridden by an equivalent global, it can give it the
weak_odr linkage type, and the optimizers will understand that it
is alright to make deductions based on the function body. The
code generators on the other hand map weak and weak_odr linkage
to the same thing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66339 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-07 15:45:40 +00:00
|
|
|
static LinkageTypes getLinkOnceLinkage(bool ODR) {
|
|
|
|
return ODR ? LinkOnceODRLinkage : LinkOnceAnyLinkage;
|
|
|
|
}
|
|
|
|
static LinkageTypes getWeakLinkage(bool ODR) {
|
|
|
|
return ODR ? WeakODRLinkage : WeakAnyLinkage;
|
|
|
|
}
|
|
|
|
|
2010-03-06 07:22:39 +00:00
|
|
|
static bool isExternalLinkage(LinkageTypes Linkage) {
|
|
|
|
return Linkage == ExternalLinkage;
|
|
|
|
}
|
|
|
|
static bool isAvailableExternallyLinkage(LinkageTypes Linkage) {
|
2009-04-13 05:44:34 +00:00
|
|
|
return Linkage == AvailableExternallyLinkage;
|
|
|
|
}
|
2010-03-06 07:22:39 +00:00
|
|
|
static bool isLinkOnceLinkage(LinkageTypes Linkage) {
|
2013-11-01 17:09:14 +00:00
|
|
|
return Linkage == LinkOnceAnyLinkage || Linkage == LinkOnceODRLinkage;
|
Introduce new linkage types linkonce_odr, weak_odr, common_odr
and extern_weak_odr. These are the same as the non-odr versions,
except that they indicate that the global will only be overridden
by an *equivalent* global. In C, a function with weak linkage can
be overridden by a function which behaves completely differently.
This means that IP passes have to skip weak functions, since any
deductions made from the function definition might be wrong, since
the definition could be replaced by something completely different
at link time. This is not allowed in C++, thanks to the ODR
(One-Definition-Rule): if a function is replaced by another at
link-time, then the new function must be the same as the original
function. If a language knows that a function or other global can
only be overridden by an equivalent global, it can give it the
weak_odr linkage type, and the optimizers will understand that it
is alright to make deductions based on the function body. The
code generators on the other hand map weak and weak_odr linkage
to the same thing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66339 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-07 15:45:40 +00:00
|
|
|
}
|
2014-05-09 00:36:18 +00:00
|
|
|
static bool isWeakAnyLinkage(LinkageTypes Linkage) {
|
|
|
|
return Linkage == WeakAnyLinkage;
|
|
|
|
}
|
|
|
|
static bool isWeakODRLinkage(LinkageTypes Linkage) {
|
|
|
|
return Linkage == WeakODRLinkage;
|
|
|
|
}
|
2010-03-06 07:22:39 +00:00
|
|
|
static bool isWeakLinkage(LinkageTypes Linkage) {
|
2014-05-09 00:36:18 +00:00
|
|
|
return isWeakAnyLinkage(Linkage) || isWeakODRLinkage(Linkage);
|
Introduce new linkage types linkonce_odr, weak_odr, common_odr
and extern_weak_odr. These are the same as the non-odr versions,
except that they indicate that the global will only be overridden
by an *equivalent* global. In C, a function with weak linkage can
be overridden by a function which behaves completely differently.
This means that IP passes have to skip weak functions, since any
deductions made from the function definition might be wrong, since
the definition could be replaced by something completely different
at link time. This is not allowed in C++, thanks to the ODR
(One-Definition-Rule): if a function is replaced by another at
link-time, then the new function must be the same as the original
function. If a language knows that a function or other global can
only be overridden by an equivalent global, it can give it the
weak_odr linkage type, and the optimizers will understand that it
is alright to make deductions based on the function body. The
code generators on the other hand map weak and weak_odr linkage
to the same thing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66339 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-07 15:45:40 +00:00
|
|
|
}
|
2010-03-06 07:22:39 +00:00
|
|
|
static bool isAppendingLinkage(LinkageTypes Linkage) {
|
|
|
|
return Linkage == AppendingLinkage;
|
|
|
|
}
|
|
|
|
static bool isInternalLinkage(LinkageTypes Linkage) {
|
|
|
|
return Linkage == InternalLinkage;
|
|
|
|
}
|
|
|
|
static bool isPrivateLinkage(LinkageTypes Linkage) {
|
|
|
|
return Linkage == PrivateLinkage;
|
|
|
|
}
|
|
|
|
static bool isLocalLinkage(LinkageTypes Linkage) {
|
Remove the linker_private and linker_private_weak linkages.
These linkages were introduced some time ago, but it was never very
clear what exactly their semantics were or what they should be used
for. Some investigation found these uses:
* utf-16 strings in clang.
* non-unnamed_addr strings produced by the sanitizers.
It turns out they were just working around a more fundamental problem.
For some sections a MachO linker needs a symbol in order to split the
section into atoms, and llvm had no idea that was the case. I fixed
that in r201700 and it is now safe to use the private linkage. When
the object ends up in a section that requires symbols, llvm will use a
'l' prefix instead of a 'L' prefix and things just work.
With that, these linkages were already dead, but there was a potential
future user in the objc metadata information. I am still looking at
CGObjcMac.cpp, but at this point I am convinced that linker_private
and linker_private_weak are not what they need.
The objc uses are currently split in
* Regular symbols (no '\01' prefix). LLVM already directly provides
whatever semantics they need.
* Uses of a private name (start with "\01L" or "\01l") and private
linkage. We can drop the "\01L" and "\01l" prefixes as soon as llvm
agrees with clang on L being ok or not for a given section. I have two
patches in code review for this.
* Uses of private name and weak linkage.
The last case is the one that one could think would fit one of these
linkages. That is not the case. The semantics are
* the linker will merge these symbol by *name*.
* the linker will hide them in the final DSO.
Given that the merging is done by name, any of the private (or
internal) linkages would be a bad match. They allow llvm to rename the
symbols, and that is really not what we want. From the llvm point of
view, these objects should really be (linkonce|weak)(_odr)?.
For now, just keeping the "\01l" prefix is probably the best for these
symbols. If we one day want to have a more direct support in llvm,
IMHO what we should add is not a linkage, it is just a hidden_symbol
attribute. It would be applicable to multiple linkages. For example,
on weak it would produce the current behavior we have for objc
metadata. On internal, it would be equivalent to private (and we
should then remove private).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203866 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-13 23:18:37 +00:00
|
|
|
return isInternalLinkage(Linkage) || isPrivateLinkage(Linkage);
|
2010-03-06 07:22:39 +00:00
|
|
|
}
|
|
|
|
static bool isExternalWeakLinkage(LinkageTypes Linkage) {
|
|
|
|
return Linkage == ExternalWeakLinkage;
|
|
|
|
}
|
|
|
|
static bool isCommonLinkage(LinkageTypes Linkage) {
|
|
|
|
return Linkage == CommonLinkage;
|
2009-01-15 20:18:42 +00:00
|
|
|
}
|
2001-11-26 18:46:40 +00:00
|
|
|
|
2014-05-07 17:04:45 +00:00
|
|
|
/// Whether the definition of this global may be discarded if it is not used
|
|
|
|
/// in its compilation unit.
|
2012-06-14 22:48:13 +00:00
|
|
|
static bool isDiscardableIfUnused(LinkageTypes Linkage) {
|
|
|
|
return isLinkOnceLinkage(Linkage) || isLocalLinkage(Linkage);
|
|
|
|
}
|
|
|
|
|
2014-05-07 17:04:45 +00:00
|
|
|
/// Whether the definition of this global may be replaced by something
|
|
|
|
/// non-equivalent at link time. For example, if a function has weak linkage
|
|
|
|
/// then the code defining it may be replaced by different code.
|
2010-03-06 07:22:39 +00:00
|
|
|
static bool mayBeOverridden(LinkageTypes Linkage) {
|
Remove the linker_private and linker_private_weak linkages.
These linkages were introduced some time ago, but it was never very
clear what exactly their semantics were or what they should be used
for. Some investigation found these uses:
* utf-16 strings in clang.
* non-unnamed_addr strings produced by the sanitizers.
It turns out they were just working around a more fundamental problem.
For some sections a MachO linker needs a symbol in order to split the
section into atoms, and llvm had no idea that was the case. I fixed
that in r201700 and it is now safe to use the private linkage. When
the object ends up in a section that requires symbols, llvm will use a
'l' prefix instead of a 'L' prefix and things just work.
With that, these linkages were already dead, but there was a potential
future user in the objc metadata information. I am still looking at
CGObjcMac.cpp, but at this point I am convinced that linker_private
and linker_private_weak are not what they need.
The objc uses are currently split in
* Regular symbols (no '\01' prefix). LLVM already directly provides
whatever semantics they need.
* Uses of a private name (start with "\01L" or "\01l") and private
linkage. We can drop the "\01L" and "\01l" prefixes as soon as llvm
agrees with clang on L being ok or not for a given section. I have two
patches in code review for this.
* Uses of private name and weak linkage.
The last case is the one that one could think would fit one of these
linkages. That is not the case. The semantics are
* the linker will merge these symbol by *name*.
* the linker will hide them in the final DSO.
Given that the merging is done by name, any of the private (or
internal) linkages would be a bad match. They allow llvm to rename the
symbols, and that is really not what we want. From the llvm point of
view, these objects should really be (linkonce|weak)(_odr)?.
For now, just keeping the "\01l" prefix is probably the best for these
symbols. If we one day want to have a more direct support in llvm,
IMHO what we should add is not a linkage, it is just a hidden_symbol
attribute. It would be applicable to multiple linkages. For example,
on weak it would produce the current behavior we have for objc
metadata. On internal, it would be equivalent to private (and we
should then remove private).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203866 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-13 23:18:37 +00:00
|
|
|
return Linkage == WeakAnyLinkage || Linkage == LinkOnceAnyLinkage ||
|
|
|
|
Linkage == CommonLinkage || Linkage == ExternalWeakLinkage;
|
Introduce new linkage types linkonce_odr, weak_odr, common_odr
and extern_weak_odr. These are the same as the non-odr versions,
except that they indicate that the global will only be overridden
by an *equivalent* global. In C, a function with weak linkage can
be overridden by a function which behaves completely differently.
This means that IP passes have to skip weak functions, since any
deductions made from the function definition might be wrong, since
the definition could be replaced by something completely different
at link time. This is not allowed in C++, thanks to the ODR
(One-Definition-Rule): if a function is replaced by another at
link-time, then the new function must be the same as the original
function. If a language knows that a function or other global can
only be overridden by an equivalent global, it can give it the
weak_odr linkage type, and the optimizers will understand that it
is alright to make deductions based on the function body. The
code generators on the other hand map weak and weak_odr linkage
to the same thing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66339 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-07 15:45:40 +00:00
|
|
|
}
|
|
|
|
|
2014-05-07 17:04:45 +00:00
|
|
|
/// Whether the definition of this global may be replaced at link time. NB:
|
|
|
|
/// Using this method outside of the code generators is almost always a
|
|
|
|
/// mistake: when working at the IR level use mayBeOverridden instead as it
|
|
|
|
/// knows about ODR semantics.
|
2010-03-06 07:22:39 +00:00
|
|
|
static bool isWeakForLinker(LinkageTypes Linkage) {
|
Remove the linker_private and linker_private_weak linkages.
These linkages were introduced some time ago, but it was never very
clear what exactly their semantics were or what they should be used
for. Some investigation found these uses:
* utf-16 strings in clang.
* non-unnamed_addr strings produced by the sanitizers.
It turns out they were just working around a more fundamental problem.
For some sections a MachO linker needs a symbol in order to split the
section into atoms, and llvm had no idea that was the case. I fixed
that in r201700 and it is now safe to use the private linkage. When
the object ends up in a section that requires symbols, llvm will use a
'l' prefix instead of a 'L' prefix and things just work.
With that, these linkages were already dead, but there was a potential
future user in the objc metadata information. I am still looking at
CGObjcMac.cpp, but at this point I am convinced that linker_private
and linker_private_weak are not what they need.
The objc uses are currently split in
* Regular symbols (no '\01' prefix). LLVM already directly provides
whatever semantics they need.
* Uses of a private name (start with "\01L" or "\01l") and private
linkage. We can drop the "\01L" and "\01l" prefixes as soon as llvm
agrees with clang on L being ok or not for a given section. I have two
patches in code review for this.
* Uses of private name and weak linkage.
The last case is the one that one could think would fit one of these
linkages. That is not the case. The semantics are
* the linker will merge these symbol by *name*.
* the linker will hide them in the final DSO.
Given that the merging is done by name, any of the private (or
internal) linkages would be a bad match. They allow llvm to rename the
symbols, and that is really not what we want. From the llvm point of
view, these objects should really be (linkonce|weak)(_odr)?.
For now, just keeping the "\01l" prefix is probably the best for these
symbols. If we one day want to have a more direct support in llvm,
IMHO what we should add is not a linkage, it is just a hidden_symbol
attribute. It would be applicable to multiple linkages. For example,
on weak it would produce the current behavior we have for objc
metadata. On internal, it would be equivalent to private (and we
should then remove private).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203866 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-13 23:18:37 +00:00
|
|
|
return Linkage == AvailableExternallyLinkage || Linkage == WeakAnyLinkage ||
|
|
|
|
Linkage == WeakODRLinkage || Linkage == LinkOnceAnyLinkage ||
|
|
|
|
Linkage == LinkOnceODRLinkage || Linkage == CommonLinkage ||
|
|
|
|
Linkage == ExternalWeakLinkage;
|
2008-07-05 23:48:30 +00:00
|
|
|
}
|
|
|
|
|
2010-03-06 07:22:39 +00:00
|
|
|
bool hasExternalLinkage() const { return isExternalLinkage(Linkage); }
|
|
|
|
bool hasAvailableExternallyLinkage() const {
|
|
|
|
return isAvailableExternallyLinkage(Linkage);
|
|
|
|
}
|
|
|
|
bool hasLinkOnceLinkage() const {
|
|
|
|
return isLinkOnceLinkage(Linkage);
|
|
|
|
}
|
|
|
|
bool hasWeakLinkage() const {
|
|
|
|
return isWeakLinkage(Linkage);
|
|
|
|
}
|
2014-05-09 00:36:18 +00:00
|
|
|
bool hasWeakAnyLinkage() const {
|
|
|
|
return isWeakAnyLinkage(Linkage);
|
|
|
|
}
|
|
|
|
bool hasWeakODRLinkage() const {
|
|
|
|
return isWeakODRLinkage(Linkage);
|
|
|
|
}
|
2010-03-06 07:22:39 +00:00
|
|
|
bool hasAppendingLinkage() const { return isAppendingLinkage(Linkage); }
|
|
|
|
bool hasInternalLinkage() const { return isInternalLinkage(Linkage); }
|
|
|
|
bool hasPrivateLinkage() const { return isPrivateLinkage(Linkage); }
|
|
|
|
bool hasLocalLinkage() const { return isLocalLinkage(Linkage); }
|
|
|
|
bool hasExternalWeakLinkage() const { return isExternalWeakLinkage(Linkage); }
|
|
|
|
bool hasCommonLinkage() const { return isCommonLinkage(Linkage); }
|
|
|
|
|
2014-05-07 23:00:22 +00:00
|
|
|
void setLinkage(LinkageTypes LT) {
|
2014-05-20 19:00:58 +00:00
|
|
|
if (isLocalLinkage(LT))
|
|
|
|
Visibility = DefaultVisibility;
|
2014-05-07 23:00:22 +00:00
|
|
|
Linkage = LT;
|
|
|
|
}
|
2010-03-06 07:22:39 +00:00
|
|
|
LinkageTypes getLinkage() const { return Linkage; }
|
|
|
|
|
2012-06-14 22:48:13 +00:00
|
|
|
bool isDiscardableIfUnused() const {
|
|
|
|
return isDiscardableIfUnused(Linkage);
|
|
|
|
}
|
|
|
|
|
2010-03-06 07:22:39 +00:00
|
|
|
bool mayBeOverridden() const { return mayBeOverridden(Linkage); }
|
|
|
|
|
|
|
|
bool isWeakForLinker() const { return isWeakForLinker(Linkage); }
|
|
|
|
|
2014-05-07 17:04:45 +00:00
|
|
|
/// Copy all additional attributes (those not needed to create a GlobalValue)
|
|
|
|
/// from the GlobalValue Src to this one.
|
2008-05-26 19:58:59 +00:00
|
|
|
virtual void copyAttributesFrom(const GlobalValue *Src);
|
|
|
|
|
2014-05-07 17:04:45 +00:00
|
|
|
/// If special LLVM prefix that is used to inform the asm printer to not emit
|
|
|
|
/// usual symbol prefix before the symbol name is used then return linkage
|
|
|
|
/// name after skipping this special LLVM prefix.
|
2013-06-01 17:51:14 +00:00
|
|
|
static StringRef getRealLinkageName(StringRef Name) {
|
|
|
|
if (!Name.empty() && Name[0] == '\1')
|
|
|
|
return Name.substr(1);
|
|
|
|
return Name;
|
|
|
|
}
|
|
|
|
|
2010-01-27 20:34:15 +00:00
|
|
|
/// @name Materialization
|
|
|
|
/// Materialization is used to construct functions only as they're needed. This
|
|
|
|
/// is useful to reduce memory usage in LLVM or parsing work done by the
|
|
|
|
/// BitcodeReader to load the Module.
|
|
|
|
/// @{
|
|
|
|
|
2014-05-07 17:04:45 +00:00
|
|
|
/// If this function's Module is being lazily streamed in functions from disk
|
|
|
|
/// or some other source, this method can be used to check to see if the
|
|
|
|
/// function has been read in yet or not.
|
2010-01-27 20:34:15 +00:00
|
|
|
bool isMaterializable() const;
|
|
|
|
|
2014-05-07 17:04:45 +00:00
|
|
|
/// Returns true if this function was loaded from a GVMaterializer that's
|
|
|
|
/// still attached to its Module and that knows how to dematerialize the
|
|
|
|
/// function.
|
2010-01-27 20:34:15 +00:00
|
|
|
bool isDematerializable() const;
|
|
|
|
|
2014-05-07 17:04:45 +00:00
|
|
|
/// Make sure this GlobalValue is fully read. If the module is corrupt, this
|
|
|
|
/// returns true and fills in the optional string with information about the
|
|
|
|
/// problem. If successful, this returns false.
|
2014-04-09 06:08:46 +00:00
|
|
|
bool Materialize(std::string *ErrInfo = nullptr);
|
2010-01-27 20:34:15 +00:00
|
|
|
|
2014-05-07 17:04:45 +00:00
|
|
|
/// If this GlobalValue is read in, and if the GVMaterializer supports it,
|
|
|
|
/// release the memory for the function, and set it up to be materialized
|
|
|
|
/// lazily. If !isDematerializable(), this method is a noop.
|
2010-01-27 20:34:15 +00:00
|
|
|
void Dematerialize();
|
|
|
|
|
|
|
|
/// @}
|
2004-11-15 23:20:19 +00:00
|
|
|
|
2004-07-17 23:28:28 +00:00
|
|
|
/// Override from Constant class.
|
2014-03-05 06:35:38 +00:00
|
|
|
void destroyConstant() override;
|
2004-07-17 23:28:28 +00:00
|
|
|
|
2014-05-07 17:04:45 +00:00
|
|
|
/// Return true if the primary definition of this global value is outside of
|
|
|
|
/// the current translation unit.
|
2011-07-14 18:10:41 +00:00
|
|
|
bool isDeclaration() const;
|
2002-10-09 23:11:33 +00:00
|
|
|
|
2014-05-07 17:04:45 +00:00
|
|
|
/// This method unlinks 'this' from the containing module, but does not delete
|
|
|
|
/// it.
|
2008-08-29 07:30:15 +00:00
|
|
|
virtual void removeFromParent() = 0;
|
|
|
|
|
2014-05-07 17:04:45 +00:00
|
|
|
/// This method unlinks 'this' from the containing module and deletes it.
|
2008-08-29 07:30:15 +00:00
|
|
|
virtual void eraseFromParent() = 0;
|
|
|
|
|
2014-05-07 17:04:45 +00:00
|
|
|
/// Get the module that this global value is contained inside of...
|
2001-10-03 19:28:15 +00:00
|
|
|
inline Module *getParent() { return Parent; }
|
|
|
|
inline const Module *getParent() const { return Parent; }
|
|
|
|
|
2014-02-25 23:25:17 +00:00
|
|
|
const DataLayout *getDataLayout() const;
|
|
|
|
|
2001-10-03 14:53:21 +00:00
|
|
|
// Methods for support type inquiry through isa, cast, and dyn_cast:
|
|
|
|
static inline bool classof(const Value *V) {
|
2007-04-13 18:12:09 +00:00
|
|
|
return V->getValueID() == Value::FunctionVal ||
|
2007-04-25 14:27:10 +00:00
|
|
|
V->getValueID() == Value::GlobalVariableVal ||
|
|
|
|
V->getValueID() == Value::GlobalAliasVal;
|
2001-10-03 14:53:21 +00:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2003-11-11 22:41:34 +00:00
|
|
|
} // End llvm namespace
|
|
|
|
|
2001-10-03 14:53:21 +00:00
|
|
|
#endif
|