2003-09-30 18:37:50 +00:00
|
|
|
//===-- llvm/DerivedTypes.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
|
|
|
//===----------------------------------------------------------------------===//
|
2001-06-06 20:29:01 +00:00
|
|
|
//
|
2005-04-21 20:19:05 +00:00
|
|
|
// This file contains the declarations of classes that represent "derived
|
2001-06-06 20:29:01 +00:00
|
|
|
// types". These are things like "arrays of x" or "structure of x, y, z" or
|
2010-09-20 03:58:32 +00:00
|
|
|
// "function returning x taking (y,z) as parameters", etc...
|
2001-06-06 20:29:01 +00:00
|
|
|
//
|
|
|
|
// The implementations of these classes live in the Type.cpp file.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2013-01-10 00:45:19 +00:00
|
|
|
#ifndef LLVM_IR_DERIVEDTYPES_H
|
|
|
|
#define LLVM_IR_DERIVEDTYPES_H
|
2001-06-06 20:29:01 +00:00
|
|
|
|
2013-01-02 11:36:10 +00:00
|
|
|
#include "llvm/IR/Type.h"
|
2012-10-08 16:38:25 +00:00
|
|
|
#include "llvm/Support/Compiler.h"
|
2012-12-03 17:02:12 +00:00
|
|
|
#include "llvm/Support/DataTypes.h"
|
2001-06-06 20:29:01 +00:00
|
|
|
|
2003-11-11 22:41:34 +00:00
|
|
|
namespace llvm {
|
|
|
|
|
2004-07-08 15:54:29 +00:00
|
|
|
class Value;
|
2007-03-01 04:02:06 +00:00
|
|
|
class APInt;
|
2009-08-11 17:45:13 +00:00
|
|
|
class LLVMContext;
|
2011-06-16 21:37:15 +00:00
|
|
|
template<typename T> class ArrayRef;
|
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 StringRef;
|
2003-09-05 02:30:18 +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
|
|
|
/// Class to represent integer types. Note that this class is also used to
|
|
|
|
/// represent the built-in integer types: Int1Ty, Int8Ty, Int16Ty, Int32Ty and
|
2009-02-14 08:41:25 +00:00
|
|
|
/// Int64Ty.
|
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
|
|
|
/// @brief Integer representation type
|
2011-07-09 17:59:15 +00:00
|
|
|
class IntegerType : public Type {
|
2009-08-13 23:27:32 +00:00
|
|
|
friend class LLVMContextImpl;
|
|
|
|
|
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
|
|
|
protected:
|
2011-07-09 17:59:15 +00:00
|
|
|
explicit IntegerType(LLVMContext &C, unsigned NumBits) : Type(C, IntegerTyID){
|
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
|
|
|
setSubclassData(NumBits);
|
|
|
|
}
|
|
|
|
public:
|
|
|
|
/// This enum is just used to hold constants we need for IntegerType.
|
|
|
|
enum {
|
|
|
|
MIN_INT_BITS = 1, ///< Minimum number of bits that can be specified
|
|
|
|
MAX_INT_BITS = (1<<23)-1 ///< Maximum number of bits that can be specified
|
|
|
|
///< Note that bit width is stored in the Type classes SubclassData field
|
|
|
|
///< which has 23 bits. This yields a maximum bit width of 8,388,607 bits.
|
|
|
|
};
|
|
|
|
|
2009-02-14 08:41:25 +00:00
|
|
|
/// This static method is the primary way of constructing an IntegerType.
|
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
|
|
|
/// If an IntegerType with the same NumBits value was previously instantiated,
|
|
|
|
/// that instance will be returned. Otherwise a new one will be created. Only
|
|
|
|
/// one instance with a given NumBits value is ever created.
|
|
|
|
/// @brief Get or create an IntegerType instance.
|
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 IntegerType *get(LLVMContext &C, unsigned NumBits);
|
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
|
|
|
|
|
|
|
/// @brief Get the number of bits in this IntegerType
|
|
|
|
unsigned getBitWidth() const { return getSubclassData(); }
|
|
|
|
|
2007-01-19 21:13:56 +00:00
|
|
|
/// getBitMask - Return a bitmask with ones set for all of the bits
|
|
|
|
/// that can be set by an unsigned version of this type. This is 0xFF for
|
2008-04-09 18:24:25 +00:00
|
|
|
/// i8, 0xFFFF for i16, etc.
|
2007-01-19 21:13:56 +00:00
|
|
|
uint64_t getBitMask() const {
|
2007-03-04 23:33:19 +00:00
|
|
|
return ~uint64_t(0UL) >> (64-getBitWidth());
|
2007-01-19 21:13:56 +00:00
|
|
|
}
|
|
|
|
|
2007-03-04 23:33:19 +00:00
|
|
|
/// getSignBit - Return a uint64_t with just the most significant bit set (the
|
|
|
|
/// sign bit, if the value is treated as a signed number).
|
|
|
|
uint64_t getSignBit() const {
|
|
|
|
return 1ULL << (getBitWidth()-1);
|
|
|
|
}
|
2009-02-14 08:41:25 +00:00
|
|
|
|
2007-03-01 02:25:03 +00:00
|
|
|
/// For example, this is 0xFF for an 8 bit integer, 0xFFFF for i16, etc.
|
|
|
|
/// @returns a bit mask with ones set for all the bits of this type.
|
|
|
|
/// @brief Get a bit mask for this type.
|
2007-03-01 04:02:06 +00:00
|
|
|
APInt getMask() const;
|
2007-03-01 02:25:03 +00:00
|
|
|
|
2007-01-18 02:59:54 +00:00
|
|
|
/// This method determines if the width of this IntegerType is a power-of-2
|
2009-02-14 08:41:25 +00:00
|
|
|
/// in terms of 8 bit bytes.
|
2007-01-18 02:59:54 +00:00
|
|
|
/// @returns true if this is a power-of-2 byte width.
|
|
|
|
/// @brief Is this a power-of-2 byte-width IntegerType ?
|
|
|
|
bool isPowerOf2ByteWidth() const;
|
|
|
|
|
2013-03-01 16:49:35 +00:00
|
|
|
/// Methods for support type inquiry through isa, cast, and dyn_cast.
|
2007-01-12 22:11:53 +00:00
|
|
|
static inline bool classof(const Type *T) {
|
|
|
|
return T->getTypeID() == IntegerTyID;
|
|
|
|
}
|
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
|
|
|
};
|
|
|
|
|
2001-09-07 16:19:29 +00:00
|
|
|
|
2004-02-10 21:49:59 +00:00
|
|
|
/// FunctionType - Class to represent function types
|
|
|
|
///
|
2011-07-09 17:59:15 +00:00
|
|
|
class FunctionType : public Type {
|
2012-09-16 21:37:56 +00:00
|
|
|
FunctionType(const FunctionType &) LLVM_DELETED_FUNCTION;
|
|
|
|
const FunctionType &operator=(const FunctionType &) LLVM_DELETED_FUNCTION;
|
2011-07-18 04:54:35 +00:00
|
|
|
FunctionType(Type *Result, ArrayRef<Type*> Params, bool IsVarArgs);
|
2001-09-07 16:19:29 +00:00
|
|
|
|
2001-06-06 20:29:01 +00:00
|
|
|
public:
|
2003-10-03 18:46:24 +00:00
|
|
|
/// FunctionType::get - This static method is the primary way of constructing
|
2009-02-14 08:41:25 +00:00
|
|
|
/// a FunctionType.
|
2004-02-10 21:49:59 +00:00
|
|
|
///
|
2011-07-18 04:54:35 +00:00
|
|
|
static FunctionType *get(Type *Result,
|
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
|
|
|
ArrayRef<Type*> Params, bool isVarArg);
|
2009-02-14 08:41:25 +00:00
|
|
|
|
2009-07-01 04:13:31 +00:00
|
|
|
/// FunctionType::get - Create a FunctionType taking no parameters.
|
|
|
|
///
|
2011-07-18 04:54:35 +00:00
|
|
|
static FunctionType *get(Type *Result, bool isVarArg);
|
2011-06-16 21:37:15 +00:00
|
|
|
|
2008-04-23 05:36:34 +00:00
|
|
|
/// isValidReturnType - Return true if the specified type is valid as a return
|
|
|
|
/// type.
|
2011-07-18 04:54:35 +00:00
|
|
|
static bool isValidReturnType(Type *RetTy);
|
2001-06-06 20:29:01 +00:00
|
|
|
|
2009-06-07 07:26:46 +00:00
|
|
|
/// isValidArgumentType - Return true if the specified type is valid as an
|
|
|
|
/// argument type.
|
2011-07-18 04:54:35 +00:00
|
|
|
static bool isValidArgumentType(Type *ArgTy);
|
2009-06-07 07:26:46 +00:00
|
|
|
|
2013-05-01 15:00:07 +00:00
|
|
|
bool isVarArg() const { return getSubclassData()!=0; }
|
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 *getReturnType() const { return ContainedTys[0]; }
|
2004-02-09 04:12:57 +00:00
|
|
|
|
2007-04-06 02:02:20 +00:00
|
|
|
typedef Type::subtype_iterator param_iterator;
|
|
|
|
param_iterator param_begin() const { return ContainedTys + 1; }
|
|
|
|
param_iterator param_end() const { return &ContainedTys[NumContainedTys]; }
|
2001-06-06 20:29:01 +00:00
|
|
|
|
2013-03-01 16:49:35 +00:00
|
|
|
/// Parameter type accessors.
|
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 *getParamType(unsigned i) const { return ContainedTys[i+1]; }
|
2002-03-29 19:04:19 +00:00
|
|
|
|
2004-02-10 21:49:59 +00:00
|
|
|
/// getNumParams - Return the number of fixed parameters this function type
|
|
|
|
/// requires. This does not consider varargs.
|
|
|
|
///
|
2007-04-06 02:02:20 +00:00
|
|
|
unsigned getNumParams() const { return NumContainedTys - 1; }
|
2001-09-07 16:19:29 +00:00
|
|
|
|
2013-03-01 16:49:35 +00:00
|
|
|
/// Methods for support type inquiry through isa, cast, and dyn_cast.
|
2001-10-02 03:41:24 +00:00
|
|
|
static inline bool classof(const Type *T) {
|
2004-06-17 18:19:28 +00:00
|
|
|
return T->getTypeID() == FunctionTyID;
|
2001-10-01 16:18:37 +00:00
|
|
|
}
|
2001-06-06 20:29:01 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
2004-08-20 06:00:58 +00:00
|
|
|
/// CompositeType - Common super class of ArrayType, StructType, PointerType
|
2011-06-16 21:08:21 +00:00
|
|
|
/// and VectorType.
|
2011-07-09 17:59:15 +00:00
|
|
|
class CompositeType : public Type {
|
2001-11-26 16:46:45 +00:00
|
|
|
protected:
|
2011-07-09 17:59:15 +00:00
|
|
|
explicit CompositeType(LLVMContext &C, TypeID tid) : Type(C, tid) { }
|
2001-11-26 16:46:45 +00:00
|
|
|
public:
|
|
|
|
|
2004-02-10 21:49:59 +00:00
|
|
|
/// getTypeAtIndex - Given an index value into the type, return the type of
|
|
|
|
/// the element.
|
|
|
|
///
|
2011-07-18 04:54:35 +00:00
|
|
|
Type *getTypeAtIndex(const Value *V);
|
|
|
|
Type *getTypeAtIndex(unsigned Idx);
|
2011-06-18 22:15:47 +00:00
|
|
|
bool indexValid(const Value *V) const;
|
|
|
|
bool indexValid(unsigned Idx) const;
|
2001-11-26 16:46:45 +00:00
|
|
|
|
2013-03-01 16:49:35 +00:00
|
|
|
/// Methods for support type inquiry through isa, cast, and dyn_cast.
|
2001-11-26 16:46:45 +00:00
|
|
|
static inline bool classof(const Type *T) {
|
2005-04-21 20:19:05 +00:00
|
|
|
return T->getTypeID() == ArrayTyID ||
|
2004-06-17 18:19:28 +00:00
|
|
|
T->getTypeID() == StructTyID ||
|
2004-08-20 06:00:58 +00:00
|
|
|
T->getTypeID() == PointerTyID ||
|
2010-08-28 04:09:24 +00:00
|
|
|
T->getTypeID() == VectorTyID;
|
2001-11-26 16:46:45 +00:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
|
2011-08-12 17:31:02 +00:00
|
|
|
/// StructType - Class to represent struct types. There are two different kinds
|
|
|
|
/// of struct types: Literal structs and Identified structs.
|
|
|
|
///
|
|
|
|
/// Literal struct types (e.g. { i32, i32 }) are uniqued structurally, and must
|
|
|
|
/// always have a body when created. You can get one of these by using one of
|
|
|
|
/// the StructType::get() forms.
|
|
|
|
///
|
|
|
|
/// Identified structs (e.g. %foo or %42) may optionally have a name and are not
|
|
|
|
/// uniqued. The names for identified structs are managed at the LLVMContext
|
|
|
|
/// level, so there can only be a single identified struct with a given name in
|
|
|
|
/// a particular LLVMContext. Identified structs may also optionally be opaque
|
|
|
|
/// (have no body specified). You get one of these by using one of the
|
|
|
|
/// StructType::create() forms.
|
|
|
|
///
|
|
|
|
/// Independent of what kind of struct you have, the body of a struct type are
|
|
|
|
/// laid out in memory consequtively with the elements directly one after the
|
|
|
|
/// other (if the struct is packed) or (if not packed) with padding between the
|
2012-10-08 16:38:25 +00:00
|
|
|
/// elements as defined by DataLayout (which is required to match what the code
|
2011-08-12 17:31:02 +00:00
|
|
|
/// generator for a target expects).
|
2004-02-10 21:49:59 +00:00
|
|
|
///
|
2004-02-09 04:36:50 +00:00
|
|
|
class StructType : public CompositeType {
|
2012-09-16 21:37:56 +00:00
|
|
|
StructType(const StructType &) LLVM_DELETED_FUNCTION;
|
|
|
|
const StructType &operator=(const StructType &) LLVM_DELETED_FUNCTION;
|
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
|
|
|
StructType(LLVMContext &C)
|
|
|
|
: CompositeType(C, StructTyID), SymbolTableEntry(0) {}
|
|
|
|
enum {
|
2013-03-01 16:49:35 +00:00
|
|
|
/// This is the contents of the SubClassData field.
|
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
|
|
|
SCDB_HasBody = 1,
|
|
|
|
SCDB_Packed = 2,
|
2012-03-07 02:33:09 +00:00
|
|
|
SCDB_IsLiteral = 4,
|
|
|
|
SCDB_IsSized = 8
|
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
|
|
|
};
|
2012-03-07 02:33:09 +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
|
|
|
/// SymbolTableEntry - For a named struct that actually has a name, this is a
|
|
|
|
/// pointer to the symbol table entry (maintained by LLVMContext) for the
|
2011-08-12 17:31:02 +00:00
|
|
|
/// struct. This is null if the type is an literal struct or if it is
|
|
|
|
/// a identified type that has an empty name.
|
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 *SymbolTableEntry;
|
2001-06-06 20:29:01 +00:00
|
|
|
public:
|
2011-07-12 18:22:07 +00:00
|
|
|
~StructType() {
|
|
|
|
delete [] ContainedTys; // Delete the body.
|
|
|
|
}
|
|
|
|
|
2011-08-12 17:31:02 +00:00
|
|
|
/// StructType::create - This creates an identified struct.
|
|
|
|
static StructType *create(LLVMContext &Context, StringRef Name);
|
|
|
|
static StructType *create(LLVMContext &Context);
|
|
|
|
|
|
|
|
static StructType *create(ArrayRef<Type*> Elements,
|
|
|
|
StringRef Name,
|
|
|
|
bool isPacked = false);
|
|
|
|
static StructType *create(ArrayRef<Type*> Elements);
|
|
|
|
static StructType *create(LLVMContext &Context,
|
|
|
|
ArrayRef<Type*> Elements,
|
|
|
|
StringRef Name,
|
|
|
|
bool isPacked = false);
|
|
|
|
static StructType *create(LLVMContext &Context, ArrayRef<Type*> Elements);
|
|
|
|
static StructType *create(StringRef Name, Type *elt1, ...) END_WITH_NULL;
|
|
|
|
|
2003-10-03 18:46:24 +00:00
|
|
|
/// StructType::get - This static method is the primary way to create a
|
2011-08-12 17:31:02 +00:00
|
|
|
/// literal StructType.
|
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 StructType *get(LLVMContext &Context, ArrayRef<Type*> Elements,
|
|
|
|
bool isPacked = false);
|
2003-10-03 18:46:24 +00:00
|
|
|
|
2009-07-01 04:13:31 +00:00
|
|
|
/// StructType::get - Create an empty structure type.
|
|
|
|
///
|
2011-06-18 22:48:56 +00:00
|
|
|
static StructType *get(LLVMContext &Context, bool isPacked = false);
|
2011-06-16 21:37:15 +00:00
|
|
|
|
2011-06-18 22:48:56 +00:00
|
|
|
/// StructType::get - This static method is a convenience method for creating
|
|
|
|
/// structure types by specifying the elements as arguments. Note that this
|
|
|
|
/// method always returns a non-packed struct, and requires at least one
|
|
|
|
/// element type.
|
2011-07-12 14:06:48 +00:00
|
|
|
static StructType *get(Type *elt1, ...) END_WITH_NULL;
|
2008-03-19 05:06:05 +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 isPacked() const { return (getSubclassData() & SCDB_Packed) != 0; }
|
|
|
|
|
2011-08-12 17:31:02 +00:00
|
|
|
/// isLiteral - Return true if this type is uniqued by structural
|
|
|
|
/// equivalence, false if it is a struct definition.
|
2011-08-12 17:43:05 +00:00
|
|
|
bool isLiteral() const { return (getSubclassData() & SCDB_IsLiteral) != 0; }
|
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
|
|
|
|
|
|
|
/// isOpaque - Return true if this is a type with an identity that has no body
|
|
|
|
/// specified yet. These prints as 'opaque' in .ll files.
|
|
|
|
bool isOpaque() const { return (getSubclassData() & SCDB_HasBody) == 0; }
|
2012-03-07 02:33:09 +00:00
|
|
|
|
|
|
|
/// isSized - Return true if this is a sized type.
|
2013-12-07 00:13:34 +00:00
|
|
|
bool isSized(SmallPtrSet<const Type*, 4> *Visited = 0) const;
|
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
|
|
|
|
|
|
|
/// hasName - Return true if this is a named struct that has a non-empty name.
|
|
|
|
bool hasName() const { return SymbolTableEntry != 0; }
|
|
|
|
|
|
|
|
/// getName - Return the name for this struct type if it has an identity.
|
|
|
|
/// This may return an empty string for an unnamed struct type. Do not call
|
2011-08-12 17:31:02 +00:00
|
|
|
/// this on an literal 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
|
|
|
StringRef getName() const;
|
|
|
|
|
|
|
|
/// setName - Change the name of this type to the specified name, or to a name
|
2011-08-12 17:31:02 +00:00
|
|
|
/// with a suffix if there is a collision. Do not call this on an literal
|
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.
|
|
|
|
void setName(StringRef Name);
|
|
|
|
|
2011-08-12 17:31:02 +00:00
|
|
|
/// setBody - Specify a body for an opaque identified 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
|
|
|
void setBody(ArrayRef<Type*> Elements, bool isPacked = false);
|
|
|
|
void setBody(Type *elt1, ...) END_WITH_NULL;
|
|
|
|
|
2009-06-07 07:26:46 +00:00
|
|
|
/// isValidElementType - Return true if the specified type is valid as a
|
|
|
|
/// element type.
|
2011-07-18 04:54:35 +00:00
|
|
|
static bool isValidElementType(Type *ElemTy);
|
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
|
|
|
|
2011-06-16 21:08:21 +00:00
|
|
|
|
|
|
|
// Iterator access to the elements.
|
2007-04-06 02:02:20 +00:00
|
|
|
typedef Type::subtype_iterator element_iterator;
|
|
|
|
element_iterator element_begin() const { return ContainedTys; }
|
|
|
|
element_iterator element_end() const { return &ContainedTys[NumContainedTys];}
|
2004-02-09 04:36:50 +00:00
|
|
|
|
2011-06-20 03:51:04 +00:00
|
|
|
/// isLayoutIdentical - Return true if this is layout identical to the
|
|
|
|
/// specified struct.
|
2011-07-18 04:54:35 +00:00
|
|
|
bool isLayoutIdentical(StructType *Other) const;
|
2011-06-20 03:51:04 +00:00
|
|
|
|
2013-03-01 16:49:35 +00:00
|
|
|
/// Random access to the elements
|
2007-04-06 02:02:20 +00:00
|
|
|
unsigned getNumElements() const { return 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
|
|
|
Type *getElementType(unsigned N) const {
|
2007-04-06 02:02:20 +00:00
|
|
|
assert(N < NumContainedTys && "Element number out of range!");
|
2004-02-09 05:40:24 +00:00
|
|
|
return ContainedTys[N];
|
2001-07-20 19:09:11 +00:00
|
|
|
}
|
2001-09-07 16:19:29 +00:00
|
|
|
|
2013-03-01 16:49:35 +00:00
|
|
|
/// Methods for support type inquiry through isa, cast, and dyn_cast.
|
2001-10-02 03:41:24 +00:00
|
|
|
static inline bool classof(const Type *T) {
|
2004-06-17 18:19:28 +00:00
|
|
|
return T->getTypeID() == StructTyID;
|
2001-10-01 18:26:53 +00:00
|
|
|
}
|
2001-06-06 20:29:01 +00:00
|
|
|
};
|
|
|
|
|
2007-07-16 14:29:03 +00:00
|
|
|
/// SequentialType - This is the superclass of the array, pointer and vector
|
2004-08-20 06:00:58 +00:00
|
|
|
/// type classes. All of these represent "arrays" in memory. The array type
|
2004-02-10 21:49:59 +00:00
|
|
|
/// represents a specifically sized array, pointer types are unsized/unknown
|
2007-02-15 03:39:18 +00:00
|
|
|
/// size arrays, vector types represent specifically sized arrays that
|
2005-04-21 20:19:05 +00:00
|
|
|
/// allow for use of SIMD instructions. SequentialType holds the common
|
|
|
|
/// features of all, which stem from the fact that all three lay their
|
2004-08-20 06:00:58 +00:00
|
|
|
/// components out in memory identically.
|
2004-02-10 21:49:59 +00:00
|
|
|
///
|
2001-12-14 16:20:21 +00:00
|
|
|
class SequentialType : public CompositeType {
|
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 *ContainedType; ///< Storage for the single contained type.
|
2012-09-16 21:37:56 +00:00
|
|
|
SequentialType(const SequentialType &) LLVM_DELETED_FUNCTION;
|
|
|
|
const SequentialType &operator=(const SequentialType &) LLVM_DELETED_FUNCTION;
|
2007-10-17 14:56:40 +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
|
|
|
SequentialType(TypeID TID, Type *ElType)
|
|
|
|
: CompositeType(ElType->getContext(), TID), ContainedType(ElType) {
|
2009-02-14 08:41:25 +00:00
|
|
|
ContainedTys = &ContainedType;
|
2007-04-06 02:02:20 +00:00
|
|
|
NumContainedTys = 1;
|
2001-12-14 16:20:21 +00:00
|
|
|
}
|
2003-09-05 02:15:36 +00:00
|
|
|
|
2001-06-06 20:29:01 +00:00
|
|
|
public:
|
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 *getElementType() const { return ContainedTys[0]; }
|
2001-11-26 16:46:45 +00:00
|
|
|
|
2013-03-01 16:49:35 +00:00
|
|
|
/// Methods for support type inquiry through isa, cast, and dyn_cast.
|
2001-12-14 16:20:21 +00:00
|
|
|
static inline bool classof(const Type *T) {
|
2004-06-17 18:19:28 +00:00
|
|
|
return T->getTypeID() == ArrayTyID ||
|
2004-08-20 06:00:58 +00:00
|
|
|
T->getTypeID() == PointerTyID ||
|
2007-02-15 02:26:10 +00:00
|
|
|
T->getTypeID() == VectorTyID;
|
2001-12-14 16:20:21 +00:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
|
2011-06-16 21:08:21 +00:00
|
|
|
/// ArrayType - Class to represent array types.
|
2004-02-10 21:49:59 +00:00
|
|
|
///
|
2001-12-14 16:20:21 +00:00
|
|
|
class ArrayType : public SequentialType {
|
2005-01-08 20:19:27 +00:00
|
|
|
uint64_t NumElements;
|
2001-12-14 16:20:21 +00:00
|
|
|
|
2012-09-16 21:37:56 +00:00
|
|
|
ArrayType(const ArrayType &) LLVM_DELETED_FUNCTION;
|
|
|
|
const ArrayType &operator=(const ArrayType &) LLVM_DELETED_FUNCTION;
|
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
|
|
|
ArrayType(Type *ElType, uint64_t NumEl);
|
2001-12-14 16:20:21 +00:00
|
|
|
public:
|
2003-10-03 18:46:24 +00:00
|
|
|
/// ArrayType::get - This static method is the primary way to construct an
|
|
|
|
/// ArrayType
|
2004-02-10 21:49:59 +00:00
|
|
|
///
|
2011-07-18 04:54:35 +00:00
|
|
|
static ArrayType *get(Type *ElementType, uint64_t NumElements);
|
2003-10-03 18:46:24 +00:00
|
|
|
|
2009-06-07 07:26:46 +00:00
|
|
|
/// isValidElementType - Return true if the specified type is valid as a
|
|
|
|
/// element type.
|
2011-07-18 04:54:35 +00:00
|
|
|
static bool isValidElementType(Type *ElemTy);
|
2009-06-07 07:26:46 +00:00
|
|
|
|
2011-06-16 21:08:21 +00:00
|
|
|
uint64_t getNumElements() const { return NumElements; }
|
2001-11-26 16:46:45 +00:00
|
|
|
|
2013-03-01 16:49:35 +00:00
|
|
|
/// Methods for support type inquiry through isa, cast, and dyn_cast.
|
2001-10-02 03:41:24 +00:00
|
|
|
static inline bool classof(const Type *T) {
|
2004-06-17 18:19:28 +00:00
|
|
|
return T->getTypeID() == ArrayTyID;
|
2001-10-01 18:26:53 +00:00
|
|
|
}
|
2001-07-23 05:03:15 +00:00
|
|
|
};
|
2001-07-20 21:09:17 +00:00
|
|
|
|
2011-06-16 21:08:21 +00:00
|
|
|
/// VectorType - Class to represent vector types.
|
2004-08-20 06:00:58 +00:00
|
|
|
///
|
2007-02-15 02:26:10 +00:00
|
|
|
class VectorType : public SequentialType {
|
2004-08-20 06:00:58 +00:00
|
|
|
unsigned NumElements;
|
|
|
|
|
2012-09-16 21:37:56 +00:00
|
|
|
VectorType(const VectorType &) LLVM_DELETED_FUNCTION;
|
|
|
|
const VectorType &operator=(const VectorType &) LLVM_DELETED_FUNCTION;
|
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
|
|
|
VectorType(Type *ElType, unsigned NumEl);
|
2004-08-20 06:00:58 +00:00
|
|
|
public:
|
2007-02-15 02:26:10 +00:00
|
|
|
/// VectorType::get - This static method is the primary way to construct an
|
2011-06-16 21:08:21 +00:00
|
|
|
/// VectorType.
|
2004-08-20 06:00:58 +00:00
|
|
|
///
|
2011-07-18 04:54:35 +00:00
|
|
|
static VectorType *get(Type *ElementType, unsigned NumElements);
|
2004-08-20 06:00:58 +00:00
|
|
|
|
2008-05-12 19:01:56 +00:00
|
|
|
/// VectorType::getInteger - This static method gets a VectorType with the
|
|
|
|
/// same number of elements as the input type, and the element type is an
|
|
|
|
/// integer type of the same width as the input element type.
|
|
|
|
///
|
2011-07-18 04:54:35 +00:00
|
|
|
static VectorType *getInteger(VectorType *VTy) {
|
2008-05-12 19:01:56 +00:00
|
|
|
unsigned EltBits = VTy->getElementType()->getPrimitiveSizeInBits();
|
2011-12-05 06:29:09 +00:00
|
|
|
assert(EltBits && "Element size must be of a non-zero size");
|
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 *EltTy = IntegerType::get(VTy->getContext(), EltBits);
|
2008-05-12 19:01:56 +00:00
|
|
|
return VectorType::get(EltTy, VTy->getNumElements());
|
|
|
|
}
|
|
|
|
|
2009-01-07 00:09:01 +00:00
|
|
|
/// VectorType::getExtendedElementVectorType - This static method is like
|
|
|
|
/// getInteger except that the element types are twice as wide as the
|
|
|
|
/// elements in the input type.
|
|
|
|
///
|
2011-07-18 04:54:35 +00:00
|
|
|
static VectorType *getExtendedElementVectorType(VectorType *VTy) {
|
2009-01-07 00:09:01 +00:00
|
|
|
unsigned EltBits = VTy->getElementType()->getPrimitiveSizeInBits();
|
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 *EltTy = IntegerType::get(VTy->getContext(), EltBits * 2);
|
2009-01-07 00:09:01 +00:00
|
|
|
return VectorType::get(EltTy, VTy->getNumElements());
|
|
|
|
}
|
|
|
|
|
|
|
|
/// VectorType::getTruncatedElementVectorType - This static method is like
|
|
|
|
/// getInteger except that the element types are half as wide as the
|
|
|
|
/// elements in the input type.
|
|
|
|
///
|
2011-07-18 04:54:35 +00:00
|
|
|
static VectorType *getTruncatedElementVectorType(VectorType *VTy) {
|
2009-01-07 00:09:01 +00:00
|
|
|
unsigned EltBits = VTy->getElementType()->getPrimitiveSizeInBits();
|
2009-01-07 23:44:27 +00:00
|
|
|
assert((EltBits & 1) == 0 &&
|
|
|
|
"Cannot truncate vector element with odd bit-width");
|
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 *EltTy = IntegerType::get(VTy->getContext(), EltBits / 2);
|
2009-01-07 00:09:01 +00:00
|
|
|
return VectorType::get(EltTy, VTy->getNumElements());
|
|
|
|
}
|
|
|
|
|
2014-03-29 07:04:54 +00:00
|
|
|
/// VectorType::getHalfElementsVectorType - This static method returns
|
|
|
|
/// a VectorType with half as many elements as the input type and the
|
|
|
|
/// same element type.
|
|
|
|
///
|
|
|
|
static VectorType *getHalfElementsVectorType(VectorType *VTy) {
|
|
|
|
unsigned NumElts = VTy->getNumElements();
|
|
|
|
assert ((NumElts & 1) == 0 &&
|
|
|
|
"Cannot halve vector with odd number of elements.");
|
|
|
|
return VectorType::get(VTy->getElementType(), NumElts/2);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// VectorType::getDoubleElementsVectorType - This static method returns
|
|
|
|
/// a VectorType with twice as many elements as the input type and the
|
|
|
|
/// same element type.
|
|
|
|
///
|
|
|
|
static VectorType *getDoubleElementsVectorType(VectorType *VTy) {
|
|
|
|
unsigned NumElts = VTy->getNumElements();
|
|
|
|
return VectorType::get(VTy->getElementType(), NumElts*2);
|
|
|
|
}
|
|
|
|
|
2009-06-07 07:26:46 +00:00
|
|
|
/// isValidElementType - Return true if the specified type is valid as a
|
|
|
|
/// element type.
|
2011-07-18 04:54:35 +00:00
|
|
|
static bool isValidElementType(Type *ElemTy);
|
2009-06-07 07:26:46 +00:00
|
|
|
|
2007-02-15 02:26:10 +00:00
|
|
|
/// @brief Return the number of elements in the Vector type.
|
2011-06-16 21:08:21 +00:00
|
|
|
unsigned getNumElements() const { return NumElements; }
|
2004-08-20 06:00:58 +00:00
|
|
|
|
2007-02-15 02:26:10 +00:00
|
|
|
/// @brief Return the number of bits in the Vector type.
|
2011-12-05 06:29:09 +00:00
|
|
|
/// Returns zero when the vector is a vector of pointers.
|
2011-06-16 21:08:21 +00:00
|
|
|
unsigned getBitWidth() const {
|
2009-08-03 22:30:18 +00:00
|
|
|
return NumElements * getElementType()->getPrimitiveSizeInBits();
|
2006-11-15 03:02:41 +00:00
|
|
|
}
|
|
|
|
|
2013-03-01 16:49:35 +00:00
|
|
|
/// Methods for support type inquiry through isa, cast, and dyn_cast.
|
2004-08-20 06:00:58 +00:00
|
|
|
static inline bool classof(const Type *T) {
|
2007-02-15 02:26:10 +00:00
|
|
|
return T->getTypeID() == VectorTyID;
|
2004-08-20 06:00:58 +00:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2001-07-20 21:09:17 +00:00
|
|
|
|
2011-06-16 21:17:17 +00:00
|
|
|
/// PointerType - Class to represent pointers.
|
2004-02-10 21:49:59 +00:00
|
|
|
///
|
2001-12-14 16:20:21 +00:00
|
|
|
class PointerType : public SequentialType {
|
2012-09-16 21:37:56 +00:00
|
|
|
PointerType(const PointerType &) LLVM_DELETED_FUNCTION;
|
|
|
|
const PointerType &operator=(const PointerType &) LLVM_DELETED_FUNCTION;
|
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
|
|
|
explicit PointerType(Type *ElType, unsigned AddrSpace);
|
2001-06-06 20:29:01 +00:00
|
|
|
public:
|
2009-02-14 08:41:25 +00:00
|
|
|
/// PointerType::get - This constructs a pointer to an object of the specified
|
2007-12-17 01:12:55 +00:00
|
|
|
/// type in a numbered address space.
|
2011-07-18 04:54:35 +00:00
|
|
|
static PointerType *get(Type *ElementType, unsigned AddressSpace);
|
2009-02-14 08:41:25 +00:00
|
|
|
|
|
|
|
/// PointerType::getUnqual - This constructs a pointer to an object of the
|
2007-12-17 01:12:55 +00:00
|
|
|
/// specified type in the generic address space (address space zero).
|
2011-07-18 04:54:35 +00:00
|
|
|
static PointerType *getUnqual(Type *ElementType) {
|
2007-12-17 01:12:55 +00:00
|
|
|
return PointerType::get(ElementType, 0);
|
|
|
|
}
|
2009-02-14 08:41:25 +00:00
|
|
|
|
2009-06-07 07:26:46 +00:00
|
|
|
/// isValidElementType - Return true if the specified type is valid as a
|
|
|
|
/// element type.
|
2011-07-18 04:54:35 +00:00
|
|
|
static bool isValidElementType(Type *ElemTy);
|
2009-06-07 07:26:46 +00:00
|
|
|
|
2007-12-11 08:59:05 +00:00
|
|
|
/// @brief Return the address space of the Pointer type.
|
2011-06-16 21:17:17 +00:00
|
|
|
inline unsigned getAddressSpace() const { return getSubclassData(); }
|
2001-09-07 16:19:29 +00:00
|
|
|
|
2013-03-01 16:49:35 +00:00
|
|
|
/// Implement support type inquiry through isa, cast, and dyn_cast.
|
2001-10-02 03:41:24 +00:00
|
|
|
static inline bool classof(const Type *T) {
|
2004-06-17 18:19:28 +00:00
|
|
|
return T->getTypeID() == PointerTyID;
|
2001-10-01 18:26:53 +00:00
|
|
|
}
|
2001-09-07 16:19:29 +00:00
|
|
|
};
|
|
|
|
|
2003-11-11 22:41:34 +00:00
|
|
|
} // End llvm namespace
|
|
|
|
|
2001-06-06 20:29:01 +00:00
|
|
|
#endif
|