2003-09-30 18:37:50 +00:00
|
|
|
//===-- llvm/Type.h - Classes for handling data types -----------*- 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
|
|
|
//===----------------------------------------------------------------------===//
|
2011-06-16 21:00:43 +00:00
|
|
|
//
|
|
|
|
// This file contains the declaration of the Type class. For more "Type"
|
|
|
|
// stuff, look in DerivedTypes.h.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
2006-05-30 15:49:30 +00:00
|
|
|
|
2001-06-06 20:29:01 +00:00
|
|
|
#ifndef LLVM_TYPE_H
|
|
|
|
#define LLVM_TYPE_H
|
|
|
|
|
2004-09-01 22:55:40 +00:00
|
|
|
#include "llvm/Support/Casting.h"
|
2001-06-06 20:29:01 +00:00
|
|
|
|
2003-11-11 22:41:34 +00:00
|
|
|
namespace llvm {
|
|
|
|
|
2001-07-20 19:12:34 +00:00
|
|
|
class PointerType;
|
2007-01-19 21:13:56 +00:00
|
|
|
class IntegerType;
|
2008-08-23 22:23:09 +00:00
|
|
|
class raw_ostream;
|
2008-10-01 20:16:19 +00:00
|
|
|
class Module;
|
2009-10-27 17:08:31 +00:00
|
|
|
class LLVMContext;
|
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
|
|
|
class LLVMContextImpl;
|
2011-06-16 21:49:23 +00:00
|
|
|
template<class GraphType> struct GraphTraits;
|
2001-06-06 20:29:01 +00:00
|
|
|
|
2006-05-30 15:49:30 +00:00
|
|
|
/// The instances of the Type class are immutable: once they are created,
|
|
|
|
/// they are never changed. Also note that only one instance of a particular
|
|
|
|
/// type is ever created. Thus seeing if two types are equal is a matter of
|
|
|
|
/// doing a trivial pointer comparison. To enforce that no two equal instances
|
|
|
|
/// are created, Type instances can only be created via static factory methods
|
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
|
|
|
/// in class Type and in derived classes. Once allocated, Types are never
|
|
|
|
/// free'd.
|
2006-05-30 15:49:30 +00:00
|
|
|
///
|
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
|
|
|
class Type {
|
2004-09-28 01:59:17 +00:00
|
|
|
public:
|
2011-06-18 21:02:49 +00:00
|
|
|
//===--------------------------------------------------------------------===//
|
2002-08-25 22:54:55 +00:00
|
|
|
/// Definitions of all of the base types for the Type system. Based on this
|
2011-07-09 17:59:15 +00:00
|
|
|
/// value, you can cast to a class defined in DerivedTypes.h.
|
2005-04-21 20:19:05 +00:00
|
|
|
/// Note: If you add an element to this, you need to add an element to the
|
2002-08-25 22:54:55 +00:00
|
|
|
/// Type::getPrimitiveType function, or else things will break!
|
2009-07-15 22:00:31 +00:00
|
|
|
/// Also update LLVMTypeKind and LLVMGetTypeKind () in the C binding.
|
2002-08-25 22:54:55 +00:00
|
|
|
///
|
2004-06-17 18:19:28 +00:00
|
|
|
enum TypeID {
|
2011-06-18 21:18:23 +00:00
|
|
|
// PrimitiveTypes - make sure LastPrimitiveTyID stays up to date.
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
VoidTyID = 0, ///< 0: type with no size
|
2011-06-18 21:02:49 +00:00
|
|
|
FloatTyID, ///< 1: 32-bit floating point type
|
|
|
|
DoubleTyID, ///< 2: 64-bit floating point type
|
|
|
|
X86_FP80TyID, ///< 3: 80-bit floating point type (X87)
|
|
|
|
FP128TyID, ///< 4: 128-bit floating point type (112-bit mantissa)
|
|
|
|
PPC_FP128TyID, ///< 5: 128-bit floating point type (two 64-bits, PowerPC)
|
2007-08-03 01:03:46 +00:00
|
|
|
LabelTyID, ///< 6: Labels
|
2009-05-30 05:06:04 +00:00
|
|
|
MetadataTyID, ///< 7: Metadata
|
2011-06-18 21:02:49 +00:00
|
|
|
X86_MMXTyID, ///< 8: MMX vectors (64 bits, X86 specific)
|
2001-06-06 20:29:01 +00:00
|
|
|
|
2011-06-18 21:02:49 +00:00
|
|
|
// Derived types... see DerivedTypes.h file.
|
|
|
|
// Make sure FirstDerivedTyID stays up to date!
|
2010-09-10 20:55:01 +00:00
|
|
|
IntegerTyID, ///< 9: Arbitrary bit width integers
|
|
|
|
FunctionTyID, ///< 10: Functions
|
|
|
|
StructTyID, ///< 11: Structures
|
|
|
|
ArrayTyID, ///< 12: Arrays
|
|
|
|
PointerTyID, ///< 13: 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
|
|
|
VectorTyID, ///< 14: SIMD 'packed' format, or other vector type
|
2001-06-06 20:29:01 +00:00
|
|
|
|
2004-06-17 18:19:28 +00:00
|
|
|
NumTypeIDs, // Must remain as last defined ID
|
2010-09-10 20:55:01 +00:00
|
|
|
LastPrimitiveTyID = X86_MMXTyID,
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
FirstDerivedTyID = IntegerTyID
|
2001-06-06 20:29:01 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
private:
|
2009-07-15 22:50:23 +00:00
|
|
|
/// Context - This refers to the LLVMContext in which this type was uniqued.
|
|
|
|
LLVMContext &Context;
|
|
|
|
|
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
|
|
|
TypeID ID : 8; // The current base type of this type.
|
|
|
|
unsigned SubclassData : 24; // Space for subclasses to store data
|
2007-04-06 02:02:20 +00:00
|
|
|
|
2001-06-06 20:29:01 +00:00
|
|
|
protected:
|
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
|
|
|
friend class LLVMContextImpl;
|
|
|
|
explicit Type(LLVMContext &C, TypeID tid)
|
|
|
|
: Context(C), ID(tid), SubclassData(0),
|
|
|
|
NumContainedTys(0), ContainedTys(0) {}
|
|
|
|
~Type() {}
|
2004-02-17 03:03:36 +00:00
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
unsigned getSubclassData() const { return SubclassData; }
|
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
|
|
|
void setSubclassData(unsigned val) {
|
|
|
|
SubclassData = val;
|
|
|
|
// Ensure we don't have any accidental truncation.
|
|
|
|
assert(SubclassData == val && "Subclass data too large for field");
|
|
|
|
}
|
2007-04-06 02:02:20 +00:00
|
|
|
|
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
|
|
|
/// NumContainedTys - Keeps track of how many Type*'s there are in the
|
|
|
|
/// ContainedTys list.
|
2007-04-06 02:02:20 +00:00
|
|
|
unsigned NumContainedTys;
|
|
|
|
|
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
|
|
|
/// ContainedTys - A pointer to the array of Types contained by this Type.
|
|
|
|
/// For example, this includes the arguments of a function type, the elements
|
|
|
|
/// of a structure, the pointee of a pointer, the element type of an array,
|
|
|
|
/// etc. This pointer may be 0 for types that don't contain other types
|
|
|
|
/// (Integer, Double, Float).
|
|
|
|
Type * const *ContainedTys;
|
2007-04-06 02:02:20 +00:00
|
|
|
|
2001-09-07 16:23:59 +00:00
|
|
|
public:
|
2008-08-23 22:23:09 +00:00
|
|
|
void print(raw_ostream &O) const;
|
2005-03-02 03:43:55 +00:00
|
|
|
void dump() const;
|
2004-05-25 08:46:04 +00:00
|
|
|
|
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
|
|
|
/// getContext - Return the LLVMContext in which this type was uniqued.
|
2009-07-15 22:50:23 +00:00
|
|
|
LLVMContext &getContext() const { return Context; }
|
|
|
|
|
2001-09-07 16:23:59 +00:00
|
|
|
//===--------------------------------------------------------------------===//
|
2011-06-18 21:18:23 +00:00
|
|
|
// Accessors for working with types.
|
2001-09-07 16:23:59 +00:00
|
|
|
//
|
|
|
|
|
2004-06-17 18:19:28 +00:00
|
|
|
/// getTypeID - Return the type id for the type. This will return one
|
|
|
|
/// of the TypeID enum elements defined above.
|
2002-08-25 22:54:55 +00:00
|
|
|
///
|
2011-06-18 21:18:23 +00:00
|
|
|
TypeID getTypeID() const { return ID; }
|
2001-09-07 16:23:59 +00:00
|
|
|
|
2009-10-05 05:48:40 +00:00
|
|
|
/// isVoidTy - Return true if this is 'void'.
|
|
|
|
bool isVoidTy() const { return ID == VoidTyID; }
|
|
|
|
|
|
|
|
/// isFloatTy - Return true if this is 'float', a 32-bit IEEE fp type.
|
|
|
|
bool isFloatTy() const { return ID == FloatTyID; }
|
|
|
|
|
|
|
|
/// isDoubleTy - Return true if this is 'double', a 64-bit IEEE fp type.
|
|
|
|
bool isDoubleTy() const { return ID == DoubleTyID; }
|
|
|
|
|
|
|
|
/// isX86_FP80Ty - Return true if this is x86 long double.
|
|
|
|
bool isX86_FP80Ty() const { return ID == X86_FP80TyID; }
|
|
|
|
|
|
|
|
/// isFP128Ty - Return true if this is 'fp128'.
|
|
|
|
bool isFP128Ty() const { return ID == FP128TyID; }
|
|
|
|
|
|
|
|
/// isPPC_FP128Ty - Return true if this is powerpc long double.
|
|
|
|
bool isPPC_FP128Ty() const { return ID == PPC_FP128TyID; }
|
|
|
|
|
2010-02-16 14:50:09 +00:00
|
|
|
/// isFloatingPointTy - Return true if this is one of the five floating point
|
|
|
|
/// types
|
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
|
|
|
bool isFloatingPointTy() const {
|
|
|
|
return ID == FloatTyID || ID == DoubleTyID ||
|
|
|
|
ID == X86_FP80TyID || ID == FP128TyID || ID == PPC_FP128TyID;
|
|
|
|
}
|
2010-02-16 14:50:09 +00:00
|
|
|
|
2010-09-12 22:36:13 +00:00
|
|
|
/// isX86_MMXTy - Return true if this is X86 MMX.
|
2010-09-10 20:55:01 +00:00
|
|
|
bool isX86_MMXTy() const { return ID == X86_MMXTyID; }
|
|
|
|
|
2010-02-16 14:50:09 +00:00
|
|
|
/// isFPOrFPVectorTy - Return true if this is a FP type or a vector of FP.
|
|
|
|
///
|
|
|
|
bool isFPOrFPVectorTy() const;
|
|
|
|
|
2009-10-05 05:48:40 +00:00
|
|
|
/// isLabelTy - Return true if this is 'label'.
|
|
|
|
bool isLabelTy() const { return ID == LabelTyID; }
|
|
|
|
|
|
|
|
/// isMetadataTy - Return true if this is 'metadata'.
|
|
|
|
bool isMetadataTy() const { return ID == MetadataTyID; }
|
|
|
|
|
2010-02-15 16:12:20 +00:00
|
|
|
/// isIntegerTy - True if this is an instance of IntegerType.
|
2002-08-25 22:54:55 +00:00
|
|
|
///
|
2010-02-15 16:12:20 +00:00
|
|
|
bool isIntegerTy() const { return ID == IntegerTyID; }
|
2001-09-07 16:23:59 +00:00
|
|
|
|
2010-02-15 16:12:20 +00:00
|
|
|
/// isIntegerTy - Return true if this is an IntegerType of the given width.
|
|
|
|
bool isIntegerTy(unsigned Bitwidth) const;
|
2010-01-05 20:04:48 +00:00
|
|
|
|
2010-02-15 16:12:20 +00:00
|
|
|
/// isIntOrIntVectorTy - Return true if this is an integer type or a vector of
|
2007-08-20 19:25:59 +00:00
|
|
|
/// integer types.
|
|
|
|
///
|
2010-02-15 16:12:20 +00:00
|
|
|
bool isIntOrIntVectorTy() const;
|
2007-08-20 19:25:59 +00:00
|
|
|
|
2010-02-15 16:12:20 +00:00
|
|
|
/// isFunctionTy - True if this is an instance of FunctionType.
|
2010-02-08 19:36:51 +00:00
|
|
|
///
|
2010-02-15 16:12:20 +00:00
|
|
|
bool isFunctionTy() const { return ID == FunctionTyID; }
|
2010-02-08 19:36:51 +00:00
|
|
|
|
2010-02-15 16:12:20 +00:00
|
|
|
/// isStructTy - True if this is an instance of StructType.
|
2010-02-08 19:36:51 +00:00
|
|
|
///
|
2010-02-15 16:12:20 +00:00
|
|
|
bool isStructTy() const { return ID == StructTyID; }
|
2010-02-08 19:36:51 +00:00
|
|
|
|
2010-02-15 16:12:20 +00:00
|
|
|
/// isArrayTy - True if this is an instance of ArrayType.
|
2010-02-08 19:36:51 +00:00
|
|
|
///
|
2010-02-15 16:12:20 +00:00
|
|
|
bool isArrayTy() const { return ID == ArrayTyID; }
|
2010-02-08 19:36:51 +00:00
|
|
|
|
2010-02-15 16:12:20 +00:00
|
|
|
/// isPointerTy - True if this is an instance of PointerType.
|
2010-02-08 19:36:51 +00:00
|
|
|
///
|
2010-02-15 16:12:20 +00:00
|
|
|
bool isPointerTy() const { return ID == PointerTyID; }
|
2010-02-08 19:36:51 +00:00
|
|
|
|
2010-02-15 16:12:20 +00:00
|
|
|
/// isVectorTy - True if this is an instance of VectorType.
|
2010-02-08 19:36:51 +00:00
|
|
|
///
|
2010-02-15 16:12:20 +00:00
|
|
|
bool isVectorTy() const { return ID == VectorTyID; }
|
2010-02-08 19:36:51 +00:00
|
|
|
|
2006-11-27 01:05:10 +00:00
|
|
|
/// canLosslesslyBitCastTo - Return true if this type could be converted
|
2009-06-07 07:26:46 +00:00
|
|
|
/// with a lossless BitCast to type 'Ty'. For example, i8* to i32*. BitCasts
|
2006-11-27 01:05:10 +00:00
|
|
|
/// are valid for types of the same size only where no re-interpretation of
|
|
|
|
/// the bits is done.
|
|
|
|
/// @brief Determine if this type could be losslessly bitcast to Ty
|
2011-07-18 04:54:35 +00:00
|
|
|
bool canLosslesslyBitCastTo(Type *Ty) const;
|
2001-11-26 16:47:10 +00:00
|
|
|
|
2011-05-13 15:18:06 +00:00
|
|
|
/// isEmptyTy - Return true if this type is empty, that is, it has no
|
|
|
|
/// elements or all its elements are empty.
|
|
|
|
bool isEmptyTy() const;
|
2002-05-06 16:12:53 +00:00
|
|
|
|
2002-08-25 22:54:55 +00:00
|
|
|
/// Here are some useful little methods to query what type derived types are
|
|
|
|
/// Note that all other types can just compare to see if this == Type::xxxTy;
|
|
|
|
///
|
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
|
|
|
bool isPrimitiveType() const { return ID <= LastPrimitiveTyID; }
|
|
|
|
bool isDerivedType() const { return ID >= FirstDerivedTyID; }
|
2002-05-06 16:12:53 +00:00
|
|
|
|
2008-05-21 23:35:53 +00:00
|
|
|
/// isFirstClassType - Return true if the type is "first class", meaning it
|
|
|
|
/// is a valid type for a Value.
|
2004-10-12 20:35:04 +00:00
|
|
|
///
|
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
|
|
|
bool isFirstClassType() const {
|
|
|
|
return ID != FunctionTyID && ID != VoidTyID;
|
2008-05-21 23:35:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/// isSingleValueType - Return true if the type is a valid type for a
|
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
|
|
|
/// register in codegen. This includes all first-class types except struct
|
|
|
|
/// and array types.
|
2008-05-21 23:35:53 +00:00
|
|
|
///
|
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
|
|
|
bool isSingleValueType() const {
|
|
|
|
return (ID != VoidTyID && isPrimitiveType()) ||
|
2007-02-15 02:26:10 +00:00
|
|
|
ID == IntegerTyID || ID == PointerTyID || ID == VectorTyID;
|
2002-05-06 16:12:53 +00:00
|
|
|
}
|
|
|
|
|
2008-05-30 22:40:06 +00:00
|
|
|
/// isAggregateType - Return true if the type is an aggregate type. This
|
|
|
|
/// means it is valid as the first operand of an insertvalue or
|
|
|
|
/// extractvalue instruction. This includes struct and array types, but
|
|
|
|
/// does not include vector types.
|
|
|
|
///
|
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
|
|
|
bool isAggregateType() const {
|
2010-08-28 04:09:24 +00:00
|
|
|
return ID == StructTyID || ID == ArrayTyID;
|
2008-05-30 22:40:06 +00:00
|
|
|
}
|
|
|
|
|
2002-08-25 22:54:55 +00:00
|
|
|
/// isSized - Return true if it makes sense to take the size of this type. To
|
|
|
|
/// get the actual size for a particular target, it is reasonable to use the
|
|
|
|
/// TargetData subsystem to do this.
|
|
|
|
///
|
2001-12-13 00:40:16 +00:00
|
|
|
bool isSized() const {
|
2005-01-24 16:28:03 +00:00
|
|
|
// If it's a primitive, it is always sized.
|
2010-09-15 00:52:23 +00:00
|
|
|
if (ID == IntegerTyID || isFloatingPointTy() || ID == PointerTyID ||
|
|
|
|
ID == X86_MMXTyID)
|
2005-01-24 16:00:52 +00:00
|
|
|
return true;
|
|
|
|
// If it is not something that can have a size (e.g. a function or label),
|
|
|
|
// it doesn't have a size.
|
2010-08-28 04:09:24 +00:00
|
|
|
if (ID != StructTyID && ID != ArrayTyID && ID != VectorTyID)
|
2005-01-24 16:00:52 +00:00
|
|
|
return false;
|
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
|
|
|
// Otherwise we have to try harder to decide.
|
|
|
|
return isSizedDerivedType();
|
2001-12-13 00:40:16 +00:00
|
|
|
}
|
|
|
|
|
2007-05-17 21:30:39 +00:00
|
|
|
/// getPrimitiveSizeInBits - Return the basic size of this type if it is a
|
|
|
|
/// primitive type. These are fixed by LLVM and are not target dependent.
|
|
|
|
/// This will return zero if the type does not have a size or is not a
|
|
|
|
/// primitive type.
|
2002-08-25 22:54:55 +00:00
|
|
|
///
|
2009-07-14 18:48:32 +00:00
|
|
|
/// Note that this may not reflect the size of memory allocated for an
|
|
|
|
/// instance of the type or the number of bytes that are written when an
|
2009-07-14 18:52:00 +00:00
|
|
|
/// instance of the type is stored to memory. The TargetData class provides
|
2009-07-14 18:48:32 +00:00
|
|
|
/// additional query functions to provide this information.
|
|
|
|
///
|
2005-04-23 21:59:42 +00:00
|
|
|
unsigned getPrimitiveSizeInBits() const;
|
2009-06-15 22:12:54 +00:00
|
|
|
|
|
|
|
/// getScalarSizeInBits - If this is a vector type, return the
|
|
|
|
/// getPrimitiveSizeInBits value for the element type. Otherwise return the
|
|
|
|
/// getPrimitiveSizeInBits value for this type.
|
2011-07-18 04:54:35 +00:00
|
|
|
unsigned getScalarSizeInBits();
|
2009-06-15 22:12:54 +00:00
|
|
|
|
2008-05-19 21:17:01 +00:00
|
|
|
/// getFPMantissaWidth - Return the width of the mantissa of this type. This
|
2009-06-15 22:12:54 +00:00
|
|
|
/// is only valid on floating point types. If the FP type does not
|
2008-05-19 21:17:01 +00:00
|
|
|
/// have a stable mantissa (e.g. ppc long double), this method returns -1.
|
2009-06-15 22:12:54 +00:00
|
|
|
int getFPMantissaWidth() const;
|
2002-05-06 16:12:53 +00:00
|
|
|
|
2009-06-15 22:12:54 +00:00
|
|
|
/// getScalarType - If this is a vector type, return the element type,
|
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
|
|
|
/// otherwise return 'this'.
|
2011-07-18 04:54:35 +00:00
|
|
|
Type *getScalarType();
|
2009-06-15 22:12:54 +00:00
|
|
|
|
2001-09-07 16:23:59 +00:00
|
|
|
//===--------------------------------------------------------------------===//
|
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
|
|
|
// Type Iteration support.
|
2001-09-07 16:23:59 +00:00
|
|
|
//
|
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
|
|
|
typedef Type * const *subtype_iterator;
|
2007-04-06 02:02:20 +00:00
|
|
|
subtype_iterator subtype_begin() const { return ContainedTys; }
|
|
|
|
subtype_iterator subtype_end() const { return &ContainedTys[NumContainedTys];}
|
2001-09-07 16:23:59 +00:00
|
|
|
|
2002-08-25 22:54:55 +00:00
|
|
|
/// getContainedType - This method is used to implement the type iterator
|
|
|
|
/// (defined a the end of the file). For derived types, this returns the
|
2003-10-09 20:35:15 +00:00
|
|
|
/// types 'contained' in the derived type.
|
2002-08-25 22:54:55 +00:00
|
|
|
///
|
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
|
|
|
Type *getContainedType(unsigned i) const {
|
2007-04-06 02:02:20 +00:00
|
|
|
assert(i < NumContainedTys && "Index out of range!");
|
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
|
|
|
return ContainedTys[i];
|
2003-10-09 20:35:15 +00:00
|
|
|
}
|
2001-09-07 16:23:59 +00:00
|
|
|
|
2004-02-09 05:40:24 +00:00
|
|
|
/// getNumContainedTypes - Return the number of types in the derived type.
|
|
|
|
///
|
2007-04-06 02:02:20 +00:00
|
|
|
unsigned getNumContainedTypes() const { return NumContainedTys; }
|
2001-09-07 16:23:59 +00:00
|
|
|
|
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// Static members exported by the Type class itself. Useful for getting
|
|
|
|
// instances of Type.
|
|
|
|
//
|
2001-06-06 20:29:01 +00:00
|
|
|
|
2004-07-08 22:31:37 +00:00
|
|
|
/// getPrimitiveType - Return a type based on an identifier.
|
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
|
|
|
static Type *getPrimitiveType(LLVMContext &C, TypeID IDNumber);
|
2001-06-06 20:29:01 +00:00
|
|
|
|
2001-09-07 16:23:59 +00:00
|
|
|
//===--------------------------------------------------------------------===//
|
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
|
|
|
// These are the builtin types that are always available.
|
2001-09-07 16:23:59 +00:00
|
|
|
//
|
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
|
|
|
static Type *getVoidTy(LLVMContext &C);
|
|
|
|
static Type *getLabelTy(LLVMContext &C);
|
|
|
|
static Type *getFloatTy(LLVMContext &C);
|
|
|
|
static Type *getDoubleTy(LLVMContext &C);
|
|
|
|
static Type *getMetadataTy(LLVMContext &C);
|
|
|
|
static Type *getX86_FP80Ty(LLVMContext &C);
|
|
|
|
static Type *getFP128Ty(LLVMContext &C);
|
|
|
|
static Type *getPPC_FP128Ty(LLVMContext &C);
|
|
|
|
static Type *getX86_MMXTy(LLVMContext &C);
|
|
|
|
static IntegerType *getIntNTy(LLVMContext &C, unsigned N);
|
|
|
|
static IntegerType *getInt1Ty(LLVMContext &C);
|
|
|
|
static IntegerType *getInt8Ty(LLVMContext &C);
|
|
|
|
static IntegerType *getInt16Ty(LLVMContext &C);
|
|
|
|
static IntegerType *getInt32Ty(LLVMContext &C);
|
|
|
|
static IntegerType *getInt64Ty(LLVMContext &C);
|
2001-06-06 20:29:01 +00:00
|
|
|
|
2009-10-06 15:40:36 +00:00
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// Convenience methods for getting pointer types with one of the above builtin
|
|
|
|
// types as pointee.
|
|
|
|
//
|
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
|
|
|
static PointerType *getFloatPtrTy(LLVMContext &C, unsigned AS = 0);
|
|
|
|
static PointerType *getDoublePtrTy(LLVMContext &C, unsigned AS = 0);
|
|
|
|
static PointerType *getX86_FP80PtrTy(LLVMContext &C, unsigned AS = 0);
|
|
|
|
static PointerType *getFP128PtrTy(LLVMContext &C, unsigned AS = 0);
|
|
|
|
static PointerType *getPPC_FP128PtrTy(LLVMContext &C, unsigned AS = 0);
|
|
|
|
static PointerType *getX86_MMXPtrTy(LLVMContext &C, unsigned AS = 0);
|
|
|
|
static PointerType *getIntNPtrTy(LLVMContext &C, unsigned N, unsigned AS = 0);
|
|
|
|
static PointerType *getInt1PtrTy(LLVMContext &C, unsigned AS = 0);
|
|
|
|
static PointerType *getInt8PtrTy(LLVMContext &C, unsigned AS = 0);
|
|
|
|
static PointerType *getInt16PtrTy(LLVMContext &C, unsigned AS = 0);
|
|
|
|
static PointerType *getInt32PtrTy(LLVMContext &C, unsigned AS = 0);
|
|
|
|
static PointerType *getInt64PtrTy(LLVMContext &C, unsigned AS = 0);
|
2009-10-06 15:40:36 +00:00
|
|
|
|
2002-08-25 22:54:55 +00:00
|
|
|
/// Methods for support type inquiry through isa, cast, and dyn_cast:
|
2008-05-19 20:15:12 +00:00
|
|
|
static inline bool classof(const Type *) { return true; }
|
2001-10-01 13:58:13 +00:00
|
|
|
|
2009-04-10 06:42:02 +00:00
|
|
|
/// getPointerTo - Return a pointer to the current type. This is equivalent
|
|
|
|
/// to PointerType::get(Foo, AddrSpace).
|
2011-07-18 04:54:35 +00:00
|
|
|
PointerType *getPointerTo(unsigned AddrSpace = 0);
|
2009-04-10 06:42:02 +00:00
|
|
|
|
2004-02-17 02:58:36 +00:00
|
|
|
private:
|
2004-07-02 23:20:17 +00:00
|
|
|
/// isSizedDerivedType - Derived types like structures and arrays are sized
|
|
|
|
/// iff all of the members of the type are sized as well. Since asking for
|
|
|
|
/// their size is relatively uncommon, move this operation out of line.
|
|
|
|
bool isSizedDerivedType() const;
|
2001-06-06 20:29:01 +00:00
|
|
|
};
|
|
|
|
|
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
|
|
|
// Printing of types.
|
2011-07-18 04:54:35 +00:00
|
|
|
static inline raw_ostream &operator<<(raw_ostream &OS, Type &T) {
|
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
|
|
|
T.print(OS);
|
|
|
|
return OS;
|
2004-02-17 02:58:36 +00:00
|
|
|
}
|
|
|
|
|
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
|
|
|
// allow isa<PointerType>(x) to work without DerivedTypes.h included.
|
|
|
|
template <> struct isa_impl<PointerType, Type> {
|
|
|
|
static inline bool doit(const Type &Ty) {
|
|
|
|
return Ty.getTypeID() == Type::PointerTyID;
|
|
|
|
}
|
|
|
|
};
|
2004-02-17 02:58:36 +00:00
|
|
|
|
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
|
|
|
|
2004-02-17 02:58:36 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
2005-04-21 20:19:05 +00:00
|
|
|
// Provide specializations of GraphTraits to be able to treat a type as a
|
2011-06-18 21:02:49 +00:00
|
|
|
// graph of sub types.
|
2001-09-28 22:56:31 +00:00
|
|
|
|
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
|
|
|
|
2001-09-28 22:56:31 +00:00
|
|
|
template <> struct GraphTraits<Type*> {
|
|
|
|
typedef Type NodeType;
|
|
|
|
typedef Type::subtype_iterator ChildIteratorType;
|
|
|
|
|
|
|
|
static inline NodeType *getEntryNode(Type *T) { return T; }
|
2005-04-21 20:19:05 +00:00
|
|
|
static inline ChildIteratorType child_begin(NodeType *N) {
|
|
|
|
return N->subtype_begin();
|
2001-09-28 22:56:31 +00:00
|
|
|
}
|
2005-04-21 20:19:05 +00:00
|
|
|
static inline ChildIteratorType child_end(NodeType *N) {
|
2001-09-28 22:56:31 +00:00
|
|
|
return N->subtype_end();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
template <> struct GraphTraits<const Type*> {
|
|
|
|
typedef const Type NodeType;
|
|
|
|
typedef Type::subtype_iterator ChildIteratorType;
|
|
|
|
|
2011-07-18 04:54:35 +00:00
|
|
|
static inline NodeType *getEntryNode(NodeType *T) { return T; }
|
2005-04-21 20:19:05 +00:00
|
|
|
static inline ChildIteratorType child_begin(NodeType *N) {
|
|
|
|
return N->subtype_begin();
|
2001-09-28 22:56:31 +00:00
|
|
|
}
|
2005-04-21 20:19:05 +00:00
|
|
|
static inline ChildIteratorType child_end(NodeType *N) {
|
2001-09-28 22:56:31 +00:00
|
|
|
return N->subtype_end();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2003-11-11 22:41:34 +00:00
|
|
|
} // End llvm namespace
|
|
|
|
|
2001-06-06 20:29:01 +00:00
|
|
|
#endif
|