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:
|
2011-07-18 04:54:35 +00:00
|
|
|
GlobalValue(Type *ty, ValueTy vty, Use *Ops, unsigned NumOps,
|
2009-12-29 07:12:03 +00:00
|
|
|
LinkageTypes linkage, const Twine &Name)
|
2012-01-07 21:17:16 +00:00
|
|
|
: Constant(ty, vty, Ops, NumOps), Linkage(linkage),
|
2014-01-14 15:22:47 +00:00
|
|
|
Visibility(DefaultVisibility), Alignment(0), UnnamedAddr(0),
|
|
|
|
DllStorageClass(DefaultStorageClass), Parent(0) {
|
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
|
2007-04-17 04:31:29 +00:00
|
|
|
unsigned Alignment : 16; // Alignment of this symbol, must be power of two
|
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
|
2012-01-07 21:17:16 +00:00
|
|
|
Module *Parent; // The containing module.
|
2007-04-17 04:31:29 +00:00
|
|
|
std::string Section; // Section to emit this into, empty mean default
|
2007-12-09 22:46:10 +00:00
|
|
|
public:
|
2007-12-10 02:14:30 +00:00
|
|
|
~GlobalValue() {
|
|
|
|
removeDeadConstantUsers(); // remove any dead constants using this.
|
|
|
|
}
|
|
|
|
|
2010-07-28 20:56:48 +00:00
|
|
|
unsigned getAlignment() const {
|
|
|
|
return (1u << Alignment) >> 1;
|
2005-11-06 06:44:42 +00:00
|
|
|
}
|
2010-07-28 20:56:48 +00:00
|
|
|
void setAlignment(unsigned Align);
|
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;
|
|
|
|
}
|
2007-01-12 19:20:47 +00:00
|
|
|
void setVisibility(VisibilityTypes V) { Visibility = V; }
|
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; }
|
|
|
|
|
2005-11-12 00:09:49 +00:00
|
|
|
bool hasSection() const { return !Section.empty(); }
|
|
|
|
const std::string &getSection() const { return Section; }
|
2014-02-13 18:26:41 +00:00
|
|
|
void setSection(StringRef S) {
|
|
|
|
assert((getValueID() != Value::GlobalAliasVal || S.empty()) &&
|
|
|
|
"GlobalAlias should not have a section!");
|
|
|
|
Section = S;
|
|
|
|
}
|
|
|
|
|
2004-07-17 23:28:28 +00:00
|
|
|
/// If the usage is empty (except transitively dead constants), then this
|
2010-02-10 16:03:48 +00:00
|
|
|
/// global value can be safely deleted since the destructor will
|
2004-07-17 23:28:28 +00:00
|
|
|
/// delete the dead constants as well.
|
2005-04-21 20:19:05 +00:00
|
|
|
/// @brief Determine if the usage of this global value is empty except
|
2004-07-17 23:28:28 +00:00
|
|
|
/// for transitively dead constants.
|
|
|
|
bool use_empty_except_constants();
|
2001-10-03 14:53:21 +00:00
|
|
|
|
2002-10-09 23:11:33 +00:00
|
|
|
/// getType - 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
|
|
|
}
|
2010-03-06 07:22:39 +00:00
|
|
|
static bool isWeakLinkage(LinkageTypes 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
|
|
|
return Linkage == WeakAnyLinkage || Linkage == WeakODRLinkage;
|
|
|
|
}
|
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
|
|
|
|
2012-06-14 22:48:13 +00:00
|
|
|
/// isDiscardableIfUnused - Whether the definition of this global may be
|
|
|
|
/// discarded if it is not used in its compilation unit.
|
|
|
|
static bool isDiscardableIfUnused(LinkageTypes Linkage) {
|
|
|
|
return isLinkOnceLinkage(Linkage) || isLocalLinkage(Linkage);
|
|
|
|
}
|
|
|
|
|
2008-09-29 11:25:42 +00:00
|
|
|
/// mayBeOverridden - Whether the definition of this global may be replaced
|
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
|
|
|
/// 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
|
|
|
}
|
|
|
|
|
|
|
|
/// isWeakForLinker - Whether the definition of this global may be replaced at
|
2010-12-20 10:57:01 +00:00
|
|
|
/// 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);
|
|
|
|
}
|
|
|
|
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); }
|
|
|
|
|
|
|
|
void setLinkage(LinkageTypes LT) { Linkage = LT; }
|
|
|
|
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); }
|
|
|
|
|
2008-05-26 19:58:59 +00:00
|
|
|
/// copyAttributesFrom - copy all additional attributes (those not needed to
|
|
|
|
/// create a GlobalValue) from the GlobalValue Src to this one.
|
|
|
|
virtual void copyAttributesFrom(const GlobalValue *Src);
|
|
|
|
|
2013-06-01 17:51:14 +00:00
|
|
|
/// getRealLinkageName - 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.
|
|
|
|
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.
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
/// isMaterializable - 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.
|
|
|
|
bool isMaterializable() const;
|
|
|
|
|
|
|
|
/// isDematerializable - 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.
|
|
|
|
bool isDematerializable() const;
|
|
|
|
|
|
|
|
/// Materialize - 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.
|
|
|
|
bool Materialize(std::string *ErrInfo = 0);
|
|
|
|
|
|
|
|
/// Dematerialize - 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.
|
|
|
|
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
|
|
|
|
2007-01-30 20:08:39 +00:00
|
|
|
/// isDeclaration - Return true if the primary definition of this global
|
2011-07-14 18:10:41 +00:00
|
|
|
/// value is outside of the current translation unit.
|
|
|
|
bool isDeclaration() const;
|
2002-10-09 23:11:33 +00:00
|
|
|
|
2008-08-29 07:30:15 +00:00
|
|
|
/// removeFromParent - This method unlinks 'this' from the containing module,
|
|
|
|
/// but does not delete it.
|
|
|
|
virtual void removeFromParent() = 0;
|
|
|
|
|
|
|
|
/// eraseFromParent - This method unlinks 'this' from the containing module
|
|
|
|
/// and deletes it.
|
|
|
|
virtual void eraseFromParent() = 0;
|
|
|
|
|
2002-10-09 23:11:33 +00:00
|
|
|
/// getParent - 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
|