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
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef LLVM_GLOBALVALUE_H
|
|
|
|
#define LLVM_GLOBALVALUE_H
|
|
|
|
|
2004-07-17 23:28:28 +00:00
|
|
|
#include "llvm/Constant.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 {
|
2001-10-03 14:53:21 +00:00
|
|
|
GlobalValue(const GlobalValue &); // do not implement
|
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.
|
|
|
|
LinkerPrivateLinkage, ///< Like Private, but linker removes.
|
2007-01-27 04:42:50 +00:00
|
|
|
DLLImportLinkage, ///< Function to be imported from DLL
|
2009-07-20 01:03:30 +00:00
|
|
|
DLLExportLinkage, ///< Function to be accessible from DLL.
|
|
|
|
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
|
|
|
|
2001-10-03 14:53:21 +00:00
|
|
|
protected:
|
2008-05-19 20:15:12 +00:00
|
|
|
GlobalValue(const Type *ty, ValueTy vty, Use *Ops, unsigned NumOps,
|
2009-12-29 07:12:03 +00:00
|
|
|
LinkageTypes linkage, const Twine &Name)
|
2008-05-19 20:15:12 +00:00
|
|
|
: Constant(ty, vty, Ops, NumOps), Parent(0),
|
2007-02-12 05:18:08 +00:00
|
|
|
Linkage(linkage), Visibility(DefaultVisibility), Alignment(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
|
|
|
|
|
|
|
Module *Parent;
|
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
|
|
|
|
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.
|
|
|
|
}
|
|
|
|
|
2005-11-06 06:44:42 +00:00
|
|
|
unsigned getAlignment() const { return Alignment; }
|
|
|
|
void setAlignment(unsigned Align) {
|
|
|
|
assert((Align & (Align-1)) == 0 && "Alignment is not a power of 2!");
|
|
|
|
Alignment = Align;
|
|
|
|
}
|
2007-01-12 19:20:47 +00:00
|
|
|
|
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; }
|
2005-11-06 06:44:42 +00:00
|
|
|
|
2005-11-12 00:09:49 +00:00
|
|
|
bool hasSection() const { return !Section.empty(); }
|
|
|
|
const std::string &getSection() const { return Section; }
|
2009-11-06 10:58:06 +00:00
|
|
|
void setSection(StringRef S) { Section = S; }
|
2005-11-12 00:09:49 +00:00
|
|
|
|
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.
|
2001-10-03 14:53:21 +00:00
|
|
|
inline const PointerType *getType() const {
|
2003-11-16 20:21:15 +00:00
|
|
|
return reinterpret_cast<const 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;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool hasExternalLinkage() const { return Linkage == ExternalLinkage; }
|
2009-04-13 05:44:34 +00:00
|
|
|
bool hasAvailableExternallyLinkage() const {
|
|
|
|
return Linkage == AvailableExternallyLinkage;
|
|
|
|
}
|
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
|
|
|
bool hasLinkOnceLinkage() const {
|
|
|
|
return Linkage == LinkOnceAnyLinkage || Linkage == LinkOnceODRLinkage;
|
|
|
|
}
|
|
|
|
bool hasWeakLinkage() const {
|
|
|
|
return Linkage == WeakAnyLinkage || Linkage == WeakODRLinkage;
|
|
|
|
}
|
|
|
|
bool hasAppendingLinkage() const { return Linkage == AppendingLinkage; }
|
|
|
|
bool hasInternalLinkage() const { return Linkage == InternalLinkage; }
|
|
|
|
bool hasPrivateLinkage() const { return Linkage == PrivateLinkage; }
|
2009-07-20 01:03:30 +00:00
|
|
|
bool hasLinkerPrivateLinkage() const { return Linkage==LinkerPrivateLinkage; }
|
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
|
|
|
bool hasLocalLinkage() const {
|
2009-07-20 01:03:30 +00:00
|
|
|
return hasInternalLinkage() || hasPrivateLinkage() ||
|
|
|
|
hasLinkerPrivateLinkage();
|
2009-01-15 20:18:42 +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
|
|
|
bool hasDLLImportLinkage() const { return Linkage == DLLImportLinkage; }
|
|
|
|
bool hasDLLExportLinkage() const { return Linkage == DLLExportLinkage; }
|
2009-03-11 08:08:06 +00:00
|
|
|
bool hasExternalWeakLinkage() const { return Linkage == ExternalWeakLinkage; }
|
2009-03-11 20:14:15 +00:00
|
|
|
bool hasCommonLinkage() const { return Linkage == CommonLinkage; }
|
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
|
|
|
|
2003-04-16 20:28:45 +00:00
|
|
|
void setLinkage(LinkageTypes LT) { Linkage = LT; }
|
|
|
|
LinkageTypes getLinkage() const { return Linkage; }
|
2001-11-26 18:46:40 +00:00
|
|
|
|
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.
|
2008-09-29 11:25:42 +00:00
|
|
|
bool mayBeOverridden() const {
|
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 == LinkOnceAnyLinkage ||
|
2009-03-11 20:14:15 +00:00
|
|
|
Linkage == CommonLinkage ||
|
2009-03-11 08:08:06 +00:00
|
|
|
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
|
2009-04-13 05:44:34 +00:00
|
|
|
/// link time.
|
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
|
|
|
bool isWeakForLinker() const {
|
2009-04-13 05:44:34 +00:00
|
|
|
return (Linkage == AvailableExternallyLinkage ||
|
|
|
|
Linkage == WeakAnyLinkage ||
|
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
|
|
|
Linkage == WeakODRLinkage ||
|
|
|
|
Linkage == LinkOnceAnyLinkage ||
|
|
|
|
Linkage == LinkOnceODRLinkage ||
|
2009-03-11 20:14:15 +00:00
|
|
|
Linkage == CommonLinkage ||
|
2009-03-11 08:08:06 +00:00
|
|
|
Linkage == ExternalWeakLinkage);
|
2008-07-05 23:48:30 +00:00
|
|
|
}
|
|
|
|
|
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);
|
|
|
|
|
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
|
|
|
|
|
|
|
/// Override from Constant class. No GlobalValue's are null values so this
|
|
|
|
/// always returns false.
|
2004-07-17 23:28:28 +00:00
|
|
|
virtual bool isNullValue() const { return false; }
|
|
|
|
|
|
|
|
/// Override from Constant class.
|
2009-06-20 00:24:58 +00:00
|
|
|
virtual void destroyConstant();
|
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
|
|
|
|
/// value is outside of the current translation unit...
|
|
|
|
virtual bool isDeclaration() const = 0;
|
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; }
|
|
|
|
|
2004-07-12 01:17:52 +00:00
|
|
|
/// removeDeadConstantUsers - If there are any dead constant users dangling
|
|
|
|
/// off of this global value, remove them. This method is useful for clients
|
|
|
|
/// that want to check to see if a global is unused, but don't want to deal
|
|
|
|
/// with potentially dead constants hanging off of the globals.
|
2009-03-09 05:50:45 +00:00
|
|
|
void removeDeadConstantUsers() const;
|
2004-07-12 01:17:52 +00:00
|
|
|
|
2001-10-03 14:53:21 +00:00
|
|
|
// Methods for support type inquiry through isa, cast, and dyn_cast:
|
2005-10-25 17:59:28 +00:00
|
|
|
static inline bool classof(const GlobalValue *) { return true; }
|
2001-10-03 14:53:21 +00:00
|
|
|
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
|