2003-09-30 18:37:50 +00:00
|
|
|
//===-- llvm/Target/TargetData.h - Data size & alignment info ---*- C++ -*-===//
|
2005-04-21 20:59: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:59:05 +00:00
|
|
|
//
|
2003-10-20 20:19:47 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
2001-09-18 12:38:31 +00:00
|
|
|
//
|
|
|
|
// This file defines target properties related to datatype size/offset/alignment
|
2005-04-21 20:59:05 +00:00
|
|
|
// information. It uses lazy annotations to cache information about how
|
2001-09-18 12:38:31 +00:00
|
|
|
// structure types are laid out and used.
|
|
|
|
//
|
|
|
|
// This structure should be created once, filled in if the defaults are not
|
|
|
|
// correct and then passed around by const&. None of the members functions
|
|
|
|
// require modification to the object.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef LLVM_TARGET_TARGETDATA_H
|
|
|
|
#define LLVM_TARGET_TARGETDATA_H
|
|
|
|
|
2002-09-25 23:46:56 +00:00
|
|
|
#include "llvm/Pass.h"
|
2007-02-14 05:52:17 +00:00
|
|
|
#include "llvm/ADT/SmallVector.h"
|
2010-11-29 18:16:10 +00:00
|
|
|
#include "llvm/Support/DataTypes.h"
|
2003-11-11 22:41:34 +00:00
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
|
2002-02-03 07:20:47 +00:00
|
|
|
class Value;
|
2009-05-11 19:38:09 +00:00
|
|
|
class Type;
|
|
|
|
class IntegerType;
|
|
|
|
class StructType;
|
2001-09-18 12:38:31 +00:00
|
|
|
class StructLayout;
|
2006-10-24 20:32:14 +00:00
|
|
|
class GlobalVariable;
|
2009-08-13 21:58:54 +00:00
|
|
|
class LLVMContext;
|
2011-07-19 14:01:37 +00:00
|
|
|
template<typename T>
|
|
|
|
class ArrayRef;
|
2001-09-18 12:38:31 +00:00
|
|
|
|
2007-02-14 05:52:17 +00:00
|
|
|
/// Enum used to categorize the alignment types stored by TargetAlignElem
|
|
|
|
enum AlignTypeEnum {
|
|
|
|
INTEGER_ALIGN = 'i', ///< Integer type alignment
|
2007-02-15 22:07:05 +00:00
|
|
|
VECTOR_ALIGN = 'v', ///< Vector type alignment
|
2007-02-14 05:52:17 +00:00
|
|
|
FLOAT_ALIGN = 'f', ///< Floating point type alignment
|
2007-09-07 14:52:14 +00:00
|
|
|
AGGREGATE_ALIGN = 'a', ///< Aggregate alignment
|
|
|
|
STACK_ALIGN = 's' ///< Stack objects alignment
|
2007-02-14 05:52:17 +00:00
|
|
|
};
|
2011-10-11 23:01:39 +00:00
|
|
|
|
2007-02-14 05:52:17 +00:00
|
|
|
/// Target alignment element.
|
|
|
|
///
|
|
|
|
/// Stores the alignment data associated with a given alignment type (pointer,
|
2007-07-16 14:29:03 +00:00
|
|
|
/// integer, vector, float) and type bit width.
|
2007-02-14 05:52:17 +00:00
|
|
|
///
|
|
|
|
/// @note The unusual order of elements in the structure attempts to reduce
|
|
|
|
/// padding and make the structure slightly more cache friendly.
|
|
|
|
struct TargetAlignElem {
|
2007-02-15 02:11:06 +00:00
|
|
|
AlignTypeEnum AlignType : 8; //< Alignment type (AlignTypeEnum)
|
2010-08-11 18:15:01 +00:00
|
|
|
unsigned ABIAlign; //< ABI alignment for this type/bitw
|
|
|
|
unsigned PrefAlign; //< Pref. alignment for this type/bitw
|
2007-02-19 22:35:00 +00:00
|
|
|
uint32_t TypeBitWidth; //< Type bit width
|
2007-02-14 05:52:17 +00:00
|
|
|
|
|
|
|
/// Initializer
|
2010-08-11 18:15:01 +00:00
|
|
|
static TargetAlignElem get(AlignTypeEnum align_type, unsigned abi_align,
|
|
|
|
unsigned pref_align, uint32_t bit_width);
|
2007-02-14 05:52:17 +00:00
|
|
|
/// Equality predicate
|
|
|
|
bool operator==(const TargetAlignElem &rhs) const;
|
|
|
|
};
|
|
|
|
|
2011-10-11 23:01:39 +00:00
|
|
|
/// TargetData - This class holds a parsed version of the target data layout
|
|
|
|
/// string in a module and provides methods for querying it. The target data
|
|
|
|
/// layout string is specified *by the target* - a frontend generating LLVM IR
|
|
|
|
/// is required to generate the right target data for the target being codegen'd
|
|
|
|
/// to. If some measure of portability is desired, an empty string may be
|
|
|
|
/// specified in the module.
|
2002-09-25 23:46:56 +00:00
|
|
|
class TargetData : public ImmutablePass {
|
2007-02-14 05:52:17 +00:00
|
|
|
private:
|
|
|
|
bool LittleEndian; ///< Defaults to false
|
2010-08-11 18:15:01 +00:00
|
|
|
unsigned PointerMemSize; ///< Pointer size in bytes
|
|
|
|
unsigned PointerABIAlign; ///< Pointer ABI alignment
|
|
|
|
unsigned PointerPrefAlign; ///< Pointer preferred alignment
|
2011-10-10 23:42:08 +00:00
|
|
|
unsigned StackNaturalAlign; ///< Stack natural alignment
|
2007-02-14 05:52:17 +00:00
|
|
|
|
2009-11-07 09:35:34 +00:00
|
|
|
SmallVector<unsigned char, 8> LegalIntWidths; ///< Legal Integers.
|
|
|
|
|
2009-11-07 09:23:04 +00:00
|
|
|
/// Alignments- Where the primitive type alignment data is stored.
|
|
|
|
///
|
|
|
|
/// @sa init().
|
|
|
|
/// @note Could support multiple size pointer alignments, e.g., 32-bit
|
|
|
|
/// pointers vs. 64-bit pointers by extending TargetAlignment, but for now,
|
|
|
|
/// we don't.
|
2007-02-14 05:52:17 +00:00
|
|
|
SmallVector<TargetAlignElem, 16> Alignments;
|
2009-11-07 09:23:04 +00:00
|
|
|
|
2009-11-07 09:35:34 +00:00
|
|
|
/// InvalidAlignmentElem - This member is a signal that a requested alignment
|
|
|
|
/// type and bit width were not found in the SmallVector.
|
2007-02-14 05:52:17 +00:00
|
|
|
static const TargetAlignElem InvalidAlignmentElem;
|
|
|
|
|
2009-11-18 01:03:56 +00:00
|
|
|
// The StructType -> StructLayout map.
|
2009-12-03 00:17:12 +00:00
|
|
|
mutable void *LayoutMap;
|
2009-08-21 19:59:12 +00:00
|
|
|
|
2007-02-14 05:52:17 +00:00
|
|
|
//! Set/initialize target alignments
|
2010-08-11 18:15:01 +00:00
|
|
|
void setAlignment(AlignTypeEnum align_type, unsigned abi_align,
|
|
|
|
unsigned pref_align, uint32_t bit_width);
|
2007-02-19 22:35:00 +00:00
|
|
|
unsigned getAlignmentInfo(AlignTypeEnum align_type, uint32_t bit_width,
|
2011-07-18 04:54:35 +00:00
|
|
|
bool ABIAlign, Type *Ty) const;
|
2007-02-14 05:52:17 +00:00
|
|
|
//! Internal helper method that returns requested alignment for type.
|
2011-07-18 04:54:35 +00:00
|
|
|
unsigned getAlignment(Type *Ty, bool abi_or_pref) const;
|
2007-02-14 05:52:17 +00:00
|
|
|
|
|
|
|
/// Valid alignment predicate.
|
|
|
|
///
|
|
|
|
/// Predicate that tests a TargetAlignElem reference returned by get() against
|
|
|
|
/// InvalidAlignmentElem.
|
2009-11-07 09:23:04 +00:00
|
|
|
bool validAlignment(const TargetAlignElem &align) const {
|
|
|
|
return &align != &InvalidAlignmentElem;
|
2007-02-14 05:52:17 +00:00
|
|
|
}
|
2004-04-14 17:45:48 +00:00
|
|
|
|
2001-09-18 12:38:31 +00:00
|
|
|
public:
|
2007-02-14 05:52:17 +00:00
|
|
|
/// Default ctor.
|
|
|
|
///
|
|
|
|
/// @note This has to exist, because this is a pass, but it should never be
|
|
|
|
/// used.
|
2009-11-07 09:23:04 +00:00
|
|
|
TargetData();
|
|
|
|
|
2007-02-14 05:52:17 +00:00
|
|
|
/// Constructs a TargetData from a specification string. See init().
|
2009-11-07 09:13:23 +00:00
|
|
|
explicit TargetData(StringRef TargetDescription)
|
2010-08-06 18:33:48 +00:00
|
|
|
: ImmutablePass(ID) {
|
2009-08-20 23:51:44 +00:00
|
|
|
init(TargetDescription);
|
|
|
|
}
|
2006-06-16 18:21:53 +00:00
|
|
|
|
|
|
|
/// Initialize target data from properties stored in the module.
|
2007-07-30 14:51:59 +00:00
|
|
|
explicit TargetData(const Module *M);
|
2009-08-20 23:51:44 +00:00
|
|
|
|
|
|
|
TargetData(const TargetData &TD) :
|
2010-08-06 18:33:48 +00:00
|
|
|
ImmutablePass(ID),
|
2009-08-20 23:51:44 +00:00
|
|
|
LittleEndian(TD.isLittleEndian()),
|
|
|
|
PointerMemSize(TD.PointerMemSize),
|
|
|
|
PointerABIAlign(TD.PointerABIAlign),
|
|
|
|
PointerPrefAlign(TD.PointerPrefAlign),
|
2009-11-07 09:35:34 +00:00
|
|
|
LegalIntWidths(TD.LegalIntWidths),
|
2009-08-21 19:59:12 +00:00
|
|
|
Alignments(TD.Alignments),
|
|
|
|
LayoutMap(0)
|
2009-08-20 23:51:44 +00:00
|
|
|
{ }
|
2005-04-21 20:59:05 +00:00
|
|
|
|
2001-09-18 12:38:31 +00:00
|
|
|
~TargetData(); // Not virtual, do not subclass this class
|
|
|
|
|
2007-02-14 05:52:17 +00:00
|
|
|
//! Parse a target data layout string and initialize TargetData alignments.
|
2009-11-07 09:13:23 +00:00
|
|
|
void init(StringRef TargetDescription);
|
2008-08-07 09:00:46 +00:00
|
|
|
|
2002-10-14 22:41:13 +00:00
|
|
|
/// Target endianness...
|
2009-11-07 09:35:34 +00:00
|
|
|
bool isLittleEndian() const { return LittleEndian; }
|
|
|
|
bool isBigEndian() const { return !LittleEndian; }
|
2002-10-14 22:41:13 +00:00
|
|
|
|
2006-05-12 07:01:44 +00:00
|
|
|
/// getStringRepresentation - Return the string representation of the
|
|
|
|
/// TargetData. This representation is in the same format accepted by the
|
|
|
|
/// string constructor above.
|
|
|
|
std::string getStringRepresentation() const;
|
2009-11-07 09:35:34 +00:00
|
|
|
|
2009-11-07 18:53:00 +00:00
|
|
|
/// isLegalInteger - This function returns true if the specified type is
|
2011-01-15 06:27:35 +00:00
|
|
|
/// known to be a native integer type supported by the CPU. For example,
|
2009-11-07 09:35:34 +00:00
|
|
|
/// i64 is not native on most 32-bit CPUs and i37 is not native on any known
|
2009-11-07 18:53:00 +00:00
|
|
|
/// one. This returns false if the integer width is not legal.
|
2009-11-07 09:35:34 +00:00
|
|
|
///
|
|
|
|
/// The width is specified in bits.
|
|
|
|
///
|
2009-11-07 18:53:00 +00:00
|
|
|
bool isLegalInteger(unsigned Width) const {
|
2009-12-09 08:29:32 +00:00
|
|
|
for (unsigned i = 0, e = (unsigned)LegalIntWidths.size(); i != e; ++i)
|
2009-11-07 09:35:34 +00:00
|
|
|
if (LegalIntWidths[i] == Width)
|
2009-11-07 18:53:00 +00:00
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool isIllegalInteger(unsigned Width) const {
|
|
|
|
return !isLegalInteger(Width);
|
2009-11-07 09:35:34 +00:00
|
|
|
}
|
2011-03-16 00:13:28 +00:00
|
|
|
|
2011-10-10 23:42:08 +00:00
|
|
|
/// Returns true if the given alignment exceeds the natural stack alignment.
|
|
|
|
bool exceedsNaturalStackAlignment(unsigned Align) const {
|
|
|
|
return (StackNaturalAlign != 0) && (Align > StackNaturalAlign);
|
|
|
|
}
|
|
|
|
|
2011-03-16 00:13:28 +00:00
|
|
|
/// fitsInLegalInteger - This function returns true if the specified type fits
|
|
|
|
/// in a native integer type supported by the CPU. For example, if the CPU
|
|
|
|
/// only supports i32 as a native integer type, then i27 fits in a legal
|
|
|
|
// integer type but i45 does not.
|
|
|
|
bool fitsInLegalInteger(unsigned Width) const {
|
|
|
|
for (unsigned i = 0, e = (unsigned)LegalIntWidths.size(); i != e; ++i)
|
|
|
|
if (Width <= LegalIntWidths[i])
|
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2007-02-14 05:52:17 +00:00
|
|
|
/// Target pointer alignment
|
2010-08-11 18:15:01 +00:00
|
|
|
unsigned getPointerABIAlignment() const { return PointerABIAlign; }
|
2007-02-14 05:52:17 +00:00
|
|
|
/// Return target's alignment for stack-based pointers
|
2010-08-11 18:15:01 +00:00
|
|
|
unsigned getPointerPrefAlignment() const { return PointerPrefAlign; }
|
2007-02-14 05:52:17 +00:00
|
|
|
/// Target pointer size
|
2010-08-11 18:15:01 +00:00
|
|
|
unsigned getPointerSize() const { return PointerMemSize; }
|
2007-02-14 05:52:17 +00:00
|
|
|
/// Target pointer size, in bits
|
2010-08-11 18:15:01 +00:00
|
|
|
unsigned getPointerSizeInBits() const { return 8*PointerMemSize; }
|
2006-05-12 07:01:44 +00:00
|
|
|
|
2009-05-08 17:49:48 +00:00
|
|
|
/// Size examples:
|
|
|
|
///
|
2009-05-09 07:06:46 +00:00
|
|
|
/// Type SizeInBits StoreSizeInBits AllocSizeInBits[*]
|
|
|
|
/// ---- ---------- --------------- ---------------
|
2009-05-08 17:49:48 +00:00
|
|
|
/// i1 1 8 8
|
|
|
|
/// i8 8 8 8
|
|
|
|
/// i19 19 24 32
|
|
|
|
/// i32 32 32 32
|
|
|
|
/// i100 100 104 128
|
|
|
|
/// i128 128 128 128
|
|
|
|
/// Float 32 32 32
|
|
|
|
/// Double 64 64 64
|
|
|
|
/// X86_FP80 80 80 96
|
|
|
|
///
|
2009-05-09 07:06:46 +00:00
|
|
|
/// [*] The alloc size depends on the alignment, and thus on the target.
|
2009-05-08 17:49:48 +00:00
|
|
|
/// These values are for x86-32 linux.
|
|
|
|
|
Executive summary: getTypeSize -> getTypeStoreSize / getABITypeSize.
The meaning of getTypeSize was not clear - clarifying it is important
now that we have x86 long double and arbitrary precision integers.
The issue with long double is that it requires 80 bits, and this is
not a multiple of its alignment. This gives a primitive type for
which getTypeSize differed from getABITypeSize. For arbitrary precision
integers it is even worse: there is the minimum number of bits needed to
hold the type (eg: 36 for an i36), the maximum number of bits that will
be overwriten when storing the type (40 bits for i36) and the ABI size
(i.e. the storage size rounded up to a multiple of the alignment; 64 bits
for i36).
This patch removes getTypeSize (not really - it is still there but
deprecated to allow for a gradual transition). Instead there is:
(1) getTypeSizeInBits - a number of bits that suffices to hold all
values of the type. For a primitive type, this is the minimum number
of bits. For an i36 this is 36 bits. For x86 long double it is 80.
This corresponds to gcc's TYPE_PRECISION.
(2) getTypeStoreSizeInBits - the maximum number of bits that is
written when storing the type (or read when reading it). For an
i36 this is 40 bits, for an x86 long double it is 80 bits. This
is the size alias analysis is interested in (getTypeStoreSize
returns the number of bytes). There doesn't seem to be anything
corresponding to this in gcc.
(3) getABITypeSizeInBits - this is getTypeStoreSizeInBits rounded
up to a multiple of the alignment. For an i36 this is 64, for an
x86 long double this is 96 or 128 depending on the OS. This is the
spacing between consecutive elements when you form an array out of
this type (getABITypeSize returns the number of bytes). This is
TYPE_SIZE in gcc.
Since successive elements in a SequentialType (arrays, pointers
and vectors) need to be aligned, the spacing between them will be
given by getABITypeSize. This means that the size of an array
is the length times the getABITypeSize. It also means that GEP
computations need to use getABITypeSize when computing offsets.
Furthermore, if an alloca allocates several elements at once then
these too need to be aligned, so the size of the alloca has to be
the number of elements multiplied by getABITypeSize. Logically
speaking this doesn't have to be the case when allocating just
one element, but it is simpler to also use getABITypeSize in this
case. So alloca's and mallocs should use getABITypeSize. Finally,
since gcc's only notion of size is that given by getABITypeSize, if
you want to output assembler etc the same as gcc then getABITypeSize
is the size you want.
Since a store will overwrite no more than getTypeStoreSize bytes,
and a read will read no more than that many bytes, this is the
notion of size appropriate for alias analysis calculations.
In this patch I have corrected all type size uses except some of
those in ScalarReplAggregates, lib/Codegen, lib/Target (the hard
cases). I will get around to auditing these too at some point,
but I could do with some help.
Finally, I made one change which I think wise but others might
consider pointless and suboptimal: in an unpacked struct the
amount of space allocated for a field is now given by the ABI
size rather than getTypeStoreSize. I did this because every
other place that reserves memory for a type (eg: alloca) now
uses getABITypeSize, and I didn't want to make an exception
for unpacked structs, i.e. I did it to make things more uniform.
This only effects structs containing long doubles and arbitrary
precision integers. If someone wants to pack these types more
tightly they can always use a packed struct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43620 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-01 20:53:16 +00:00
|
|
|
/// getTypeSizeInBits - Return the number of bits necessary to hold the
|
|
|
|
/// specified type. For example, returns 36 for i36 and 80 for x86_fp80.
|
2011-07-18 04:54:35 +00:00
|
|
|
uint64_t getTypeSizeInBits(Type* Ty) const;
|
Executive summary: getTypeSize -> getTypeStoreSize / getABITypeSize.
The meaning of getTypeSize was not clear - clarifying it is important
now that we have x86 long double and arbitrary precision integers.
The issue with long double is that it requires 80 bits, and this is
not a multiple of its alignment. This gives a primitive type for
which getTypeSize differed from getABITypeSize. For arbitrary precision
integers it is even worse: there is the minimum number of bits needed to
hold the type (eg: 36 for an i36), the maximum number of bits that will
be overwriten when storing the type (40 bits for i36) and the ABI size
(i.e. the storage size rounded up to a multiple of the alignment; 64 bits
for i36).
This patch removes getTypeSize (not really - it is still there but
deprecated to allow for a gradual transition). Instead there is:
(1) getTypeSizeInBits - a number of bits that suffices to hold all
values of the type. For a primitive type, this is the minimum number
of bits. For an i36 this is 36 bits. For x86 long double it is 80.
This corresponds to gcc's TYPE_PRECISION.
(2) getTypeStoreSizeInBits - the maximum number of bits that is
written when storing the type (or read when reading it). For an
i36 this is 40 bits, for an x86 long double it is 80 bits. This
is the size alias analysis is interested in (getTypeStoreSize
returns the number of bytes). There doesn't seem to be anything
corresponding to this in gcc.
(3) getABITypeSizeInBits - this is getTypeStoreSizeInBits rounded
up to a multiple of the alignment. For an i36 this is 64, for an
x86 long double this is 96 or 128 depending on the OS. This is the
spacing between consecutive elements when you form an array out of
this type (getABITypeSize returns the number of bytes). This is
TYPE_SIZE in gcc.
Since successive elements in a SequentialType (arrays, pointers
and vectors) need to be aligned, the spacing between them will be
given by getABITypeSize. This means that the size of an array
is the length times the getABITypeSize. It also means that GEP
computations need to use getABITypeSize when computing offsets.
Furthermore, if an alloca allocates several elements at once then
these too need to be aligned, so the size of the alloca has to be
the number of elements multiplied by getABITypeSize. Logically
speaking this doesn't have to be the case when allocating just
one element, but it is simpler to also use getABITypeSize in this
case. So alloca's and mallocs should use getABITypeSize. Finally,
since gcc's only notion of size is that given by getABITypeSize, if
you want to output assembler etc the same as gcc then getABITypeSize
is the size you want.
Since a store will overwrite no more than getTypeStoreSize bytes,
and a read will read no more than that many bytes, this is the
notion of size appropriate for alias analysis calculations.
In this patch I have corrected all type size uses except some of
those in ScalarReplAggregates, lib/Codegen, lib/Target (the hard
cases). I will get around to auditing these too at some point,
but I could do with some help.
Finally, I made one change which I think wise but others might
consider pointless and suboptimal: in an unpacked struct the
amount of space allocated for a field is now given by the ABI
size rather than getTypeStoreSize. I did this because every
other place that reserves memory for a type (eg: alloca) now
uses getABITypeSize, and I didn't want to make an exception
for unpacked structs, i.e. I did it to make things more uniform.
This only effects structs containing long doubles and arbitrary
precision integers. If someone wants to pack these types more
tightly they can always use a packed struct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43620 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-01 20:53:16 +00:00
|
|
|
|
|
|
|
/// getTypeStoreSize - Return the maximum number of bytes that may be
|
|
|
|
/// overwritten by storing the specified type. For example, returns 5
|
|
|
|
/// for i36 and 10 for x86_fp80.
|
2011-07-18 04:54:35 +00:00
|
|
|
uint64_t getTypeStoreSize(Type *Ty) const {
|
2010-02-25 15:20:39 +00:00
|
|
|
return (getTypeSizeInBits(Ty)+7)/8;
|
|
|
|
}
|
Executive summary: getTypeSize -> getTypeStoreSize / getABITypeSize.
The meaning of getTypeSize was not clear - clarifying it is important
now that we have x86 long double and arbitrary precision integers.
The issue with long double is that it requires 80 bits, and this is
not a multiple of its alignment. This gives a primitive type for
which getTypeSize differed from getABITypeSize. For arbitrary precision
integers it is even worse: there is the minimum number of bits needed to
hold the type (eg: 36 for an i36), the maximum number of bits that will
be overwriten when storing the type (40 bits for i36) and the ABI size
(i.e. the storage size rounded up to a multiple of the alignment; 64 bits
for i36).
This patch removes getTypeSize (not really - it is still there but
deprecated to allow for a gradual transition). Instead there is:
(1) getTypeSizeInBits - a number of bits that suffices to hold all
values of the type. For a primitive type, this is the minimum number
of bits. For an i36 this is 36 bits. For x86 long double it is 80.
This corresponds to gcc's TYPE_PRECISION.
(2) getTypeStoreSizeInBits - the maximum number of bits that is
written when storing the type (or read when reading it). For an
i36 this is 40 bits, for an x86 long double it is 80 bits. This
is the size alias analysis is interested in (getTypeStoreSize
returns the number of bytes). There doesn't seem to be anything
corresponding to this in gcc.
(3) getABITypeSizeInBits - this is getTypeStoreSizeInBits rounded
up to a multiple of the alignment. For an i36 this is 64, for an
x86 long double this is 96 or 128 depending on the OS. This is the
spacing between consecutive elements when you form an array out of
this type (getABITypeSize returns the number of bytes). This is
TYPE_SIZE in gcc.
Since successive elements in a SequentialType (arrays, pointers
and vectors) need to be aligned, the spacing between them will be
given by getABITypeSize. This means that the size of an array
is the length times the getABITypeSize. It also means that GEP
computations need to use getABITypeSize when computing offsets.
Furthermore, if an alloca allocates several elements at once then
these too need to be aligned, so the size of the alloca has to be
the number of elements multiplied by getABITypeSize. Logically
speaking this doesn't have to be the case when allocating just
one element, but it is simpler to also use getABITypeSize in this
case. So alloca's and mallocs should use getABITypeSize. Finally,
since gcc's only notion of size is that given by getABITypeSize, if
you want to output assembler etc the same as gcc then getABITypeSize
is the size you want.
Since a store will overwrite no more than getTypeStoreSize bytes,
and a read will read no more than that many bytes, this is the
notion of size appropriate for alias analysis calculations.
In this patch I have corrected all type size uses except some of
those in ScalarReplAggregates, lib/Codegen, lib/Target (the hard
cases). I will get around to auditing these too at some point,
but I could do with some help.
Finally, I made one change which I think wise but others might
consider pointless and suboptimal: in an unpacked struct the
amount of space allocated for a field is now given by the ABI
size rather than getTypeStoreSize. I did this because every
other place that reserves memory for a type (eg: alloca) now
uses getABITypeSize, and I didn't want to make an exception
for unpacked structs, i.e. I did it to make things more uniform.
This only effects structs containing long doubles and arbitrary
precision integers. If someone wants to pack these types more
tightly they can always use a packed struct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43620 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-01 20:53:16 +00:00
|
|
|
|
|
|
|
/// getTypeStoreSizeInBits - Return the maximum number of bits that may be
|
|
|
|
/// overwritten by storing the specified type; always a multiple of 8. For
|
|
|
|
/// example, returns 40 for i36 and 80 for x86_fp80.
|
2011-07-18 04:54:35 +00:00
|
|
|
uint64_t getTypeStoreSizeInBits(Type *Ty) const {
|
Executive summary: getTypeSize -> getTypeStoreSize / getABITypeSize.
The meaning of getTypeSize was not clear - clarifying it is important
now that we have x86 long double and arbitrary precision integers.
The issue with long double is that it requires 80 bits, and this is
not a multiple of its alignment. This gives a primitive type for
which getTypeSize differed from getABITypeSize. For arbitrary precision
integers it is even worse: there is the minimum number of bits needed to
hold the type (eg: 36 for an i36), the maximum number of bits that will
be overwriten when storing the type (40 bits for i36) and the ABI size
(i.e. the storage size rounded up to a multiple of the alignment; 64 bits
for i36).
This patch removes getTypeSize (not really - it is still there but
deprecated to allow for a gradual transition). Instead there is:
(1) getTypeSizeInBits - a number of bits that suffices to hold all
values of the type. For a primitive type, this is the minimum number
of bits. For an i36 this is 36 bits. For x86 long double it is 80.
This corresponds to gcc's TYPE_PRECISION.
(2) getTypeStoreSizeInBits - the maximum number of bits that is
written when storing the type (or read when reading it). For an
i36 this is 40 bits, for an x86 long double it is 80 bits. This
is the size alias analysis is interested in (getTypeStoreSize
returns the number of bytes). There doesn't seem to be anything
corresponding to this in gcc.
(3) getABITypeSizeInBits - this is getTypeStoreSizeInBits rounded
up to a multiple of the alignment. For an i36 this is 64, for an
x86 long double this is 96 or 128 depending on the OS. This is the
spacing between consecutive elements when you form an array out of
this type (getABITypeSize returns the number of bytes). This is
TYPE_SIZE in gcc.
Since successive elements in a SequentialType (arrays, pointers
and vectors) need to be aligned, the spacing between them will be
given by getABITypeSize. This means that the size of an array
is the length times the getABITypeSize. It also means that GEP
computations need to use getABITypeSize when computing offsets.
Furthermore, if an alloca allocates several elements at once then
these too need to be aligned, so the size of the alloca has to be
the number of elements multiplied by getABITypeSize. Logically
speaking this doesn't have to be the case when allocating just
one element, but it is simpler to also use getABITypeSize in this
case. So alloca's and mallocs should use getABITypeSize. Finally,
since gcc's only notion of size is that given by getABITypeSize, if
you want to output assembler etc the same as gcc then getABITypeSize
is the size you want.
Since a store will overwrite no more than getTypeStoreSize bytes,
and a read will read no more than that many bytes, this is the
notion of size appropriate for alias analysis calculations.
In this patch I have corrected all type size uses except some of
those in ScalarReplAggregates, lib/Codegen, lib/Target (the hard
cases). I will get around to auditing these too at some point,
but I could do with some help.
Finally, I made one change which I think wise but others might
consider pointless and suboptimal: in an unpacked struct the
amount of space allocated for a field is now given by the ABI
size rather than getTypeStoreSize. I did this because every
other place that reserves memory for a type (eg: alloca) now
uses getABITypeSize, and I didn't want to make an exception
for unpacked structs, i.e. I did it to make things more uniform.
This only effects structs containing long doubles and arbitrary
precision integers. If someone wants to pack these types more
tightly they can always use a packed struct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43620 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-01 20:53:16 +00:00
|
|
|
return 8*getTypeStoreSize(Ty);
|
|
|
|
}
|
|
|
|
|
2009-05-09 07:06:46 +00:00
|
|
|
/// getTypeAllocSize - Return the offset in bytes between successive objects
|
Executive summary: getTypeSize -> getTypeStoreSize / getABITypeSize.
The meaning of getTypeSize was not clear - clarifying it is important
now that we have x86 long double and arbitrary precision integers.
The issue with long double is that it requires 80 bits, and this is
not a multiple of its alignment. This gives a primitive type for
which getTypeSize differed from getABITypeSize. For arbitrary precision
integers it is even worse: there is the minimum number of bits needed to
hold the type (eg: 36 for an i36), the maximum number of bits that will
be overwriten when storing the type (40 bits for i36) and the ABI size
(i.e. the storage size rounded up to a multiple of the alignment; 64 bits
for i36).
This patch removes getTypeSize (not really - it is still there but
deprecated to allow for a gradual transition). Instead there is:
(1) getTypeSizeInBits - a number of bits that suffices to hold all
values of the type. For a primitive type, this is the minimum number
of bits. For an i36 this is 36 bits. For x86 long double it is 80.
This corresponds to gcc's TYPE_PRECISION.
(2) getTypeStoreSizeInBits - the maximum number of bits that is
written when storing the type (or read when reading it). For an
i36 this is 40 bits, for an x86 long double it is 80 bits. This
is the size alias analysis is interested in (getTypeStoreSize
returns the number of bytes). There doesn't seem to be anything
corresponding to this in gcc.
(3) getABITypeSizeInBits - this is getTypeStoreSizeInBits rounded
up to a multiple of the alignment. For an i36 this is 64, for an
x86 long double this is 96 or 128 depending on the OS. This is the
spacing between consecutive elements when you form an array out of
this type (getABITypeSize returns the number of bytes). This is
TYPE_SIZE in gcc.
Since successive elements in a SequentialType (arrays, pointers
and vectors) need to be aligned, the spacing between them will be
given by getABITypeSize. This means that the size of an array
is the length times the getABITypeSize. It also means that GEP
computations need to use getABITypeSize when computing offsets.
Furthermore, if an alloca allocates several elements at once then
these too need to be aligned, so the size of the alloca has to be
the number of elements multiplied by getABITypeSize. Logically
speaking this doesn't have to be the case when allocating just
one element, but it is simpler to also use getABITypeSize in this
case. So alloca's and mallocs should use getABITypeSize. Finally,
since gcc's only notion of size is that given by getABITypeSize, if
you want to output assembler etc the same as gcc then getABITypeSize
is the size you want.
Since a store will overwrite no more than getTypeStoreSize bytes,
and a read will read no more than that many bytes, this is the
notion of size appropriate for alias analysis calculations.
In this patch I have corrected all type size uses except some of
those in ScalarReplAggregates, lib/Codegen, lib/Target (the hard
cases). I will get around to auditing these too at some point,
but I could do with some help.
Finally, I made one change which I think wise but others might
consider pointless and suboptimal: in an unpacked struct the
amount of space allocated for a field is now given by the ABI
size rather than getTypeStoreSize. I did this because every
other place that reserves memory for a type (eg: alloca) now
uses getABITypeSize, and I didn't want to make an exception
for unpacked structs, i.e. I did it to make things more uniform.
This only effects structs containing long doubles and arbitrary
precision integers. If someone wants to pack these types more
tightly they can always use a packed struct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43620 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-01 20:53:16 +00:00
|
|
|
/// of the specified type, including alignment padding. This is the amount
|
|
|
|
/// that alloca reserves for this type. For example, returns 12 or 16 for
|
|
|
|
/// x86_fp80, depending on alignment.
|
2011-07-18 04:54:35 +00:00
|
|
|
uint64_t getTypeAllocSize(Type* Ty) const {
|
2010-02-25 15:20:39 +00:00
|
|
|
// Round up to the next alignment boundary.
|
|
|
|
return RoundUpAlignment(getTypeStoreSize(Ty), getABITypeAlignment(Ty));
|
|
|
|
}
|
2007-10-01 16:03:14 +00:00
|
|
|
|
2009-05-09 07:06:46 +00:00
|
|
|
/// getTypeAllocSizeInBits - Return the offset in bits between successive
|
Executive summary: getTypeSize -> getTypeStoreSize / getABITypeSize.
The meaning of getTypeSize was not clear - clarifying it is important
now that we have x86 long double and arbitrary precision integers.
The issue with long double is that it requires 80 bits, and this is
not a multiple of its alignment. This gives a primitive type for
which getTypeSize differed from getABITypeSize. For arbitrary precision
integers it is even worse: there is the minimum number of bits needed to
hold the type (eg: 36 for an i36), the maximum number of bits that will
be overwriten when storing the type (40 bits for i36) and the ABI size
(i.e. the storage size rounded up to a multiple of the alignment; 64 bits
for i36).
This patch removes getTypeSize (not really - it is still there but
deprecated to allow for a gradual transition). Instead there is:
(1) getTypeSizeInBits - a number of bits that suffices to hold all
values of the type. For a primitive type, this is the minimum number
of bits. For an i36 this is 36 bits. For x86 long double it is 80.
This corresponds to gcc's TYPE_PRECISION.
(2) getTypeStoreSizeInBits - the maximum number of bits that is
written when storing the type (or read when reading it). For an
i36 this is 40 bits, for an x86 long double it is 80 bits. This
is the size alias analysis is interested in (getTypeStoreSize
returns the number of bytes). There doesn't seem to be anything
corresponding to this in gcc.
(3) getABITypeSizeInBits - this is getTypeStoreSizeInBits rounded
up to a multiple of the alignment. For an i36 this is 64, for an
x86 long double this is 96 or 128 depending on the OS. This is the
spacing between consecutive elements when you form an array out of
this type (getABITypeSize returns the number of bytes). This is
TYPE_SIZE in gcc.
Since successive elements in a SequentialType (arrays, pointers
and vectors) need to be aligned, the spacing between them will be
given by getABITypeSize. This means that the size of an array
is the length times the getABITypeSize. It also means that GEP
computations need to use getABITypeSize when computing offsets.
Furthermore, if an alloca allocates several elements at once then
these too need to be aligned, so the size of the alloca has to be
the number of elements multiplied by getABITypeSize. Logically
speaking this doesn't have to be the case when allocating just
one element, but it is simpler to also use getABITypeSize in this
case. So alloca's and mallocs should use getABITypeSize. Finally,
since gcc's only notion of size is that given by getABITypeSize, if
you want to output assembler etc the same as gcc then getABITypeSize
is the size you want.
Since a store will overwrite no more than getTypeStoreSize bytes,
and a read will read no more than that many bytes, this is the
notion of size appropriate for alias analysis calculations.
In this patch I have corrected all type size uses except some of
those in ScalarReplAggregates, lib/Codegen, lib/Target (the hard
cases). I will get around to auditing these too at some point,
but I could do with some help.
Finally, I made one change which I think wise but others might
consider pointless and suboptimal: in an unpacked struct the
amount of space allocated for a field is now given by the ABI
size rather than getTypeStoreSize. I did this because every
other place that reserves memory for a type (eg: alloca) now
uses getABITypeSize, and I didn't want to make an exception
for unpacked structs, i.e. I did it to make things more uniform.
This only effects structs containing long doubles and arbitrary
precision integers. If someone wants to pack these types more
tightly they can always use a packed struct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43620 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-01 20:53:16 +00:00
|
|
|
/// objects of the specified type, including alignment padding; always a
|
|
|
|
/// multiple of 8. This is the amount that alloca reserves for this type.
|
|
|
|
/// For example, returns 96 or 128 for x86_fp80, depending on alignment.
|
2011-07-18 04:54:35 +00:00
|
|
|
uint64_t getTypeAllocSizeInBits(Type* Ty) const {
|
2009-05-09 07:06:46 +00:00
|
|
|
return 8*getTypeAllocSize(Ty);
|
Executive summary: getTypeSize -> getTypeStoreSize / getABITypeSize.
The meaning of getTypeSize was not clear - clarifying it is important
now that we have x86 long double and arbitrary precision integers.
The issue with long double is that it requires 80 bits, and this is
not a multiple of its alignment. This gives a primitive type for
which getTypeSize differed from getABITypeSize. For arbitrary precision
integers it is even worse: there is the minimum number of bits needed to
hold the type (eg: 36 for an i36), the maximum number of bits that will
be overwriten when storing the type (40 bits for i36) and the ABI size
(i.e. the storage size rounded up to a multiple of the alignment; 64 bits
for i36).
This patch removes getTypeSize (not really - it is still there but
deprecated to allow for a gradual transition). Instead there is:
(1) getTypeSizeInBits - a number of bits that suffices to hold all
values of the type. For a primitive type, this is the minimum number
of bits. For an i36 this is 36 bits. For x86 long double it is 80.
This corresponds to gcc's TYPE_PRECISION.
(2) getTypeStoreSizeInBits - the maximum number of bits that is
written when storing the type (or read when reading it). For an
i36 this is 40 bits, for an x86 long double it is 80 bits. This
is the size alias analysis is interested in (getTypeStoreSize
returns the number of bytes). There doesn't seem to be anything
corresponding to this in gcc.
(3) getABITypeSizeInBits - this is getTypeStoreSizeInBits rounded
up to a multiple of the alignment. For an i36 this is 64, for an
x86 long double this is 96 or 128 depending on the OS. This is the
spacing between consecutive elements when you form an array out of
this type (getABITypeSize returns the number of bytes). This is
TYPE_SIZE in gcc.
Since successive elements in a SequentialType (arrays, pointers
and vectors) need to be aligned, the spacing between them will be
given by getABITypeSize. This means that the size of an array
is the length times the getABITypeSize. It also means that GEP
computations need to use getABITypeSize when computing offsets.
Furthermore, if an alloca allocates several elements at once then
these too need to be aligned, so the size of the alloca has to be
the number of elements multiplied by getABITypeSize. Logically
speaking this doesn't have to be the case when allocating just
one element, but it is simpler to also use getABITypeSize in this
case. So alloca's and mallocs should use getABITypeSize. Finally,
since gcc's only notion of size is that given by getABITypeSize, if
you want to output assembler etc the same as gcc then getABITypeSize
is the size you want.
Since a store will overwrite no more than getTypeStoreSize bytes,
and a read will read no more than that many bytes, this is the
notion of size appropriate for alias analysis calculations.
In this patch I have corrected all type size uses except some of
those in ScalarReplAggregates, lib/Codegen, lib/Target (the hard
cases). I will get around to auditing these too at some point,
but I could do with some help.
Finally, I made one change which I think wise but others might
consider pointless and suboptimal: in an unpacked struct the
amount of space allocated for a field is now given by the ABI
size rather than getTypeStoreSize. I did this because every
other place that reserves memory for a type (eg: alloca) now
uses getABITypeSize, and I didn't want to make an exception
for unpacked structs, i.e. I did it to make things more uniform.
This only effects structs containing long doubles and arbitrary
precision integers. If someone wants to pack these types more
tightly they can always use a packed struct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43620 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-01 20:53:16 +00:00
|
|
|
}
|
2007-01-20 23:32:04 +00:00
|
|
|
|
2007-02-19 22:35:00 +00:00
|
|
|
/// getABITypeAlignment - Return the minimum ABI-required alignment for the
|
2007-01-20 22:35:55 +00:00
|
|
|
/// specified type.
|
2011-07-18 04:54:35 +00:00
|
|
|
unsigned getABITypeAlignment(Type *Ty) const;
|
2010-01-25 23:18:11 +00:00
|
|
|
|
|
|
|
/// getABIIntegerTypeAlignment - Return the minimum ABI-required alignment for
|
|
|
|
/// an integer type of the specified bitwidth.
|
2010-08-11 18:15:01 +00:00
|
|
|
unsigned getABIIntegerTypeAlignment(unsigned BitWidth) const;
|
2010-01-25 23:18:11 +00:00
|
|
|
|
2007-01-20 22:35:55 +00:00
|
|
|
|
2007-09-07 14:52:14 +00:00
|
|
|
/// getCallFrameTypeAlignment - Return the minimum ABI-required alignment
|
|
|
|
/// for the specified type when it is part of a call frame.
|
2011-07-18 04:54:35 +00:00
|
|
|
unsigned getCallFrameTypeAlignment(Type *Ty) const;
|
2007-09-07 14:52:14 +00:00
|
|
|
|
|
|
|
|
2007-02-19 22:35:00 +00:00
|
|
|
/// getPrefTypeAlignment - Return the preferred stack/global alignment for
|
2008-01-29 06:23:44 +00:00
|
|
|
/// the specified type. This is always at least as good as the ABI alignment.
|
2011-07-18 04:54:35 +00:00
|
|
|
unsigned getPrefTypeAlignment(Type *Ty) const;
|
2001-09-18 12:38:31 +00:00
|
|
|
|
2007-01-24 07:03:39 +00:00
|
|
|
/// getPreferredTypeAlignmentShift - Return the preferred alignment for the
|
2004-08-17 19:12:44 +00:00
|
|
|
/// specified type, returned as log2 of the value (a shift amount).
|
2005-04-23 22:35:26 +00:00
|
|
|
///
|
2011-07-18 04:54:35 +00:00
|
|
|
unsigned getPreferredTypeAlignmentShift(Type *Ty) const;
|
2004-08-17 19:12:44 +00:00
|
|
|
|
2003-12-22 05:00:45 +00:00
|
|
|
/// getIntPtrType - Return an unsigned integer type that is the same size or
|
|
|
|
/// greater to the host pointer size.
|
2005-04-23 22:35:26 +00:00
|
|
|
///
|
2011-07-12 11:36:58 +00:00
|
|
|
IntegerType *getIntPtrType(LLVMContext &C) const;
|
2003-12-22 05:00:45 +00:00
|
|
|
|
2009-01-09 04:58:01 +00:00
|
|
|
/// getIndexedOffset - return the offset from the beginning of the type for
|
|
|
|
/// the specified indices. This is used to implement getelementptr.
|
2003-12-22 05:00:45 +00:00
|
|
|
///
|
2011-07-19 14:01:37 +00:00
|
|
|
uint64_t getIndexedOffset(Type *Ty, ArrayRef<Value *> Indices) const;
|
2008-08-07 09:00:46 +00:00
|
|
|
|
2006-01-14 00:06:42 +00:00
|
|
|
/// getStructLayout - Return a StructLayout object, indicating the alignment
|
|
|
|
/// of the struct, its size, and the offsets of its fields. Note that this
|
|
|
|
/// information is lazily cached.
|
2011-07-18 04:54:35 +00:00
|
|
|
const StructLayout *getStructLayout(StructType *Ty) const;
|
2008-08-07 09:00:46 +00:00
|
|
|
|
2008-01-29 06:23:44 +00:00
|
|
|
/// getPreferredAlignment - Return the preferred alignment of the specified
|
|
|
|
/// global. This includes an explicitly requested alignment (if the global
|
|
|
|
/// has one).
|
|
|
|
unsigned getPreferredAlignment(const GlobalVariable *GV) const;
|
|
|
|
|
2006-10-24 20:32:14 +00:00
|
|
|
/// getPreferredAlignmentLog - Return the preferred alignment of the
|
|
|
|
/// specified global, returned in log form. This includes an explicitly
|
|
|
|
/// requested alignment (if the global has one).
|
2006-10-24 20:48:29 +00:00
|
|
|
unsigned getPreferredAlignmentLog(const GlobalVariable *GV) const;
|
2007-05-01 21:15:47 +00:00
|
|
|
|
2008-12-08 07:11:56 +00:00
|
|
|
/// RoundUpAlignment - Round the specified value up to the next alignment
|
|
|
|
/// boundary specified by Alignment. For example, 7 rounded up to an
|
|
|
|
/// alignment boundary of 4 is 8. 8 rounded up to the alignment boundary of 4
|
|
|
|
/// is 8 because it is already aligned.
|
|
|
|
template <typename UIntTy>
|
|
|
|
static UIntTy RoundUpAlignment(UIntTy Val, unsigned Alignment) {
|
|
|
|
assert((Alignment & (Alignment-1)) == 0 && "Alignment must be power of 2!");
|
|
|
|
return (Val + (Alignment-1)) & ~UIntTy(Alignment-1);
|
|
|
|
}
|
|
|
|
|
2007-05-06 13:37:16 +00:00
|
|
|
static char ID; // Pass identification, replacement for typeid
|
2001-09-18 12:38:31 +00:00
|
|
|
};
|
|
|
|
|
2005-04-23 22:35:26 +00:00
|
|
|
/// StructLayout - used to lazily calculate structure layout information for a
|
|
|
|
/// target machine, based on the TargetData structure.
|
|
|
|
///
|
2004-10-27 16:14:51 +00:00
|
|
|
class StructLayout {
|
2007-02-10 19:55:17 +00:00
|
|
|
uint64_t StructSize;
|
2007-02-10 20:15:41 +00:00
|
|
|
unsigned StructAlignment;
|
|
|
|
unsigned NumElements;
|
|
|
|
uint64_t MemberOffsets[1]; // variable sized array!
|
2007-02-10 19:59:22 +00:00
|
|
|
public:
|
2005-03-13 19:04:04 +00:00
|
|
|
|
2007-02-10 19:59:22 +00:00
|
|
|
uint64_t getSizeInBytes() const {
|
|
|
|
return StructSize;
|
|
|
|
}
|
2008-08-07 09:00:46 +00:00
|
|
|
|
Executive summary: getTypeSize -> getTypeStoreSize / getABITypeSize.
The meaning of getTypeSize was not clear - clarifying it is important
now that we have x86 long double and arbitrary precision integers.
The issue with long double is that it requires 80 bits, and this is
not a multiple of its alignment. This gives a primitive type for
which getTypeSize differed from getABITypeSize. For arbitrary precision
integers it is even worse: there is the minimum number of bits needed to
hold the type (eg: 36 for an i36), the maximum number of bits that will
be overwriten when storing the type (40 bits for i36) and the ABI size
(i.e. the storage size rounded up to a multiple of the alignment; 64 bits
for i36).
This patch removes getTypeSize (not really - it is still there but
deprecated to allow for a gradual transition). Instead there is:
(1) getTypeSizeInBits - a number of bits that suffices to hold all
values of the type. For a primitive type, this is the minimum number
of bits. For an i36 this is 36 bits. For x86 long double it is 80.
This corresponds to gcc's TYPE_PRECISION.
(2) getTypeStoreSizeInBits - the maximum number of bits that is
written when storing the type (or read when reading it). For an
i36 this is 40 bits, for an x86 long double it is 80 bits. This
is the size alias analysis is interested in (getTypeStoreSize
returns the number of bytes). There doesn't seem to be anything
corresponding to this in gcc.
(3) getABITypeSizeInBits - this is getTypeStoreSizeInBits rounded
up to a multiple of the alignment. For an i36 this is 64, for an
x86 long double this is 96 or 128 depending on the OS. This is the
spacing between consecutive elements when you form an array out of
this type (getABITypeSize returns the number of bytes). This is
TYPE_SIZE in gcc.
Since successive elements in a SequentialType (arrays, pointers
and vectors) need to be aligned, the spacing between them will be
given by getABITypeSize. This means that the size of an array
is the length times the getABITypeSize. It also means that GEP
computations need to use getABITypeSize when computing offsets.
Furthermore, if an alloca allocates several elements at once then
these too need to be aligned, so the size of the alloca has to be
the number of elements multiplied by getABITypeSize. Logically
speaking this doesn't have to be the case when allocating just
one element, but it is simpler to also use getABITypeSize in this
case. So alloca's and mallocs should use getABITypeSize. Finally,
since gcc's only notion of size is that given by getABITypeSize, if
you want to output assembler etc the same as gcc then getABITypeSize
is the size you want.
Since a store will overwrite no more than getTypeStoreSize bytes,
and a read will read no more than that many bytes, this is the
notion of size appropriate for alias analysis calculations.
In this patch I have corrected all type size uses except some of
those in ScalarReplAggregates, lib/Codegen, lib/Target (the hard
cases). I will get around to auditing these too at some point,
but I could do with some help.
Finally, I made one change which I think wise but others might
consider pointless and suboptimal: in an unpacked struct the
amount of space allocated for a field is now given by the ABI
size rather than getTypeStoreSize. I did this because every
other place that reserves memory for a type (eg: alloca) now
uses getABITypeSize, and I didn't want to make an exception
for unpacked structs, i.e. I did it to make things more uniform.
This only effects structs containing long doubles and arbitrary
precision integers. If someone wants to pack these types more
tightly they can always use a packed struct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43620 91177308-0d34-0410-b5e6-96231b3b80d8
2007-11-01 20:53:16 +00:00
|
|
|
uint64_t getSizeInBits() const {
|
|
|
|
return 8*StructSize;
|
|
|
|
}
|
|
|
|
|
2007-02-10 19:59:22 +00:00
|
|
|
unsigned getAlignment() const {
|
|
|
|
return StructAlignment;
|
|
|
|
}
|
2008-08-07 09:00:46 +00:00
|
|
|
|
2009-05-12 17:08:34 +00:00
|
|
|
/// getElementContainingOffset - Given a valid byte offset into the structure,
|
2005-03-13 19:04:04 +00:00
|
|
|
/// return the structure index that contains it.
|
2005-04-23 22:35:26 +00:00
|
|
|
///
|
2005-03-13 19:04:04 +00:00
|
|
|
unsigned getElementContainingOffset(uint64_t Offset) const;
|
|
|
|
|
2007-02-10 19:55:17 +00:00
|
|
|
uint64_t getElementOffset(unsigned Idx) const {
|
2007-02-10 20:15:41 +00:00
|
|
|
assert(Idx < NumElements && "Invalid element idx!");
|
2007-02-10 19:55:17 +00:00
|
|
|
return MemberOffsets[Idx];
|
|
|
|
}
|
2007-11-04 14:43:57 +00:00
|
|
|
|
|
|
|
uint64_t getElementOffsetInBits(unsigned Idx) const {
|
|
|
|
return getElementOffset(Idx)*8;
|
|
|
|
}
|
|
|
|
|
2001-09-18 12:38:31 +00:00
|
|
|
private:
|
|
|
|
friend class TargetData; // Only TargetData can create this class
|
2011-07-18 04:54:35 +00:00
|
|
|
StructLayout(StructType *ST, const TargetData &TD);
|
2001-09-18 12:38:31 +00:00
|
|
|
};
|
|
|
|
|
2003-11-11 22:41:34 +00:00
|
|
|
} // End llvm namespace
|
|
|
|
|
2001-09-18 12:38:31 +00:00
|
|
|
#endif
|