2001-08-27 16:00:15 +00:00
|
|
|
//===-- TargetData.cpp - Data size & alignment routines --------------------==//
|
2005-04-21 22:55:34 +00:00
|
|
|
//
|
2003-10-20 19:43:21 +00:00
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
2007-12-29 20:36:04 +00:00
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
2005-04-21 22:55:34 +00:00
|
|
|
//
|
2003-10-20 19:43:21 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
2001-08-27 16:00:15 +00:00
|
|
|
//
|
|
|
|
// This file defines target properties related to datatype size/offset/alignment
|
2004-02-26 08:02:17 +00:00
|
|
|
// information.
|
2001-08-27 16:00:15 +00:00
|
|
|
//
|
|
|
|
// 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.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2001-09-18 12:58:33 +00:00
|
|
|
#include "llvm/Target/TargetData.h"
|
2003-04-24 19:09:05 +00:00
|
|
|
#include "llvm/Module.h"
|
2001-08-27 16:00:15 +00:00
|
|
|
#include "llvm/DerivedTypes.h"
|
2002-04-28 19:55:58 +00:00
|
|
|
#include "llvm/Constants.h"
|
2004-04-05 01:30:19 +00:00
|
|
|
#include "llvm/Support/GetElementPtrTypeIterator.h"
|
2004-09-01 22:55:40 +00:00
|
|
|
#include "llvm/Support/MathExtras.h"
|
2007-02-10 19:43:18 +00:00
|
|
|
#include "llvm/Support/ManagedStatic.h"
|
2007-02-10 20:26:17 +00:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
2006-05-12 05:49:47 +00:00
|
|
|
#include "llvm/ADT/StringExtras.h"
|
2005-03-13 19:04:41 +00:00
|
|
|
#include <algorithm>
|
2006-05-12 05:49:47 +00:00
|
|
|
#include <cstdlib>
|
2006-05-12 07:01:44 +00:00
|
|
|
#include <sstream>
|
2003-12-22 05:01:15 +00:00
|
|
|
using namespace llvm;
|
2003-11-11 22:41:34 +00:00
|
|
|
|
2003-08-18 14:43:39 +00:00
|
|
|
// Handle the Pass registration stuff necessary to use TargetData's.
|
2002-09-25 23:46:55 +00:00
|
|
|
namespace {
|
|
|
|
// Register the default SparcV9 implementation...
|
|
|
|
RegisterPass<TargetData> X("targetdata", "Target Data Layout");
|
|
|
|
}
|
2007-05-03 01:11:54 +00:00
|
|
|
char TargetData::ID = 0;
|
2002-09-25 23:46:55 +00:00
|
|
|
|
2001-08-27 16:00:15 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
2004-02-26 08:02:17 +00:00
|
|
|
// Support for StructLayout
|
2001-08-27 16:00:15 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2004-02-26 08:02:17 +00:00
|
|
|
StructLayout::StructLayout(const StructType *ST, const TargetData &TD) {
|
2001-08-27 16:00:15 +00:00
|
|
|
StructAlignment = 0;
|
|
|
|
StructSize = 0;
|
2007-02-10 20:15:41 +00:00
|
|
|
NumElements = ST->getNumElements();
|
2001-08-27 16:00:15 +00:00
|
|
|
|
|
|
|
// Loop over each of the elements, placing them in memory...
|
2007-02-10 20:15:41 +00:00
|
|
|
for (unsigned i = 0, e = NumElements; i != e; ++i) {
|
|
|
|
const Type *Ty = ST->getElementType(i);
|
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
|
|
|
unsigned TyAlign = ST->isPacked() ?
|
|
|
|
1 : TD.getABITypeAlignment(Ty);
|
|
|
|
uint64_t TySize = ST->isPacked() ?
|
|
|
|
TD.getTypeStoreSize(Ty) : TD.getABITypeSize(Ty);
|
2001-08-27 16:00:15 +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
|
|
|
// Add padding if necessary to align the data element properly...
|
|
|
|
StructSize = (StructSize + TyAlign - 1)/TyAlign * TyAlign;
|
2001-08-27 16:00:15 +00:00
|
|
|
|
|
|
|
// Keep track of maximum alignment constraint
|
2002-01-20 22:54:45 +00:00
|
|
|
StructAlignment = std::max(TyAlign, StructAlignment);
|
2001-08-27 16:00:15 +00:00
|
|
|
|
2007-02-10 20:15:41 +00:00
|
|
|
MemberOffsets[i] = StructSize;
|
2002-05-19 15:28:02 +00:00
|
|
|
StructSize += TySize; // Consume space for this data item
|
2001-08-27 16:00:15 +00:00
|
|
|
}
|
|
|
|
|
2003-05-21 18:08:44 +00:00
|
|
|
// Empty structures have alignment of 1 byte.
|
|
|
|
if (StructAlignment == 0) StructAlignment = 1;
|
|
|
|
|
2001-08-27 16:00:15 +00:00
|
|
|
// Add padding to the end of the struct so that it could be put in an array
|
|
|
|
// and all array elements would be aligned correctly.
|
|
|
|
if (StructSize % StructAlignment != 0)
|
|
|
|
StructSize = (StructSize/StructAlignment + 1) * StructAlignment;
|
|
|
|
}
|
|
|
|
|
2005-03-13 19:04:41 +00:00
|
|
|
|
|
|
|
/// getElementContainingOffset - Given a valid offset into the structure,
|
|
|
|
/// return the structure index that contains it.
|
|
|
|
unsigned StructLayout::getElementContainingOffset(uint64_t Offset) const {
|
2007-02-10 20:15:41 +00:00
|
|
|
const uint64_t *SI =
|
|
|
|
std::upper_bound(&MemberOffsets[0], &MemberOffsets[NumElements], Offset);
|
|
|
|
assert(SI != &MemberOffsets[0] && "Offset not in structure type!");
|
2005-03-13 19:04:41 +00:00
|
|
|
--SI;
|
|
|
|
assert(*SI <= Offset && "upper_bound didn't work");
|
2007-10-29 02:40:02 +00:00
|
|
|
assert((SI == &MemberOffsets[0] || *(SI-1) <= Offset) &&
|
2007-02-10 20:15:41 +00:00
|
|
|
(SI+1 == &MemberOffsets[NumElements] || *(SI+1) > Offset) &&
|
2005-03-13 19:04:41 +00:00
|
|
|
"Upper bound didn't work!");
|
2007-10-29 02:40:02 +00:00
|
|
|
|
|
|
|
// Multiple fields can have the same offset if any of them are zero sized.
|
|
|
|
// For example, in { i32, [0 x i32], i32 }, searching for offset 4 will stop
|
|
|
|
// at the i32 element, because it is the last element at that offset. This is
|
|
|
|
// the right one to return, because anything after it will have a higher
|
|
|
|
// offset, implying that this element is non-empty.
|
2007-02-10 20:15:41 +00:00
|
|
|
return SI-&MemberOffsets[0];
|
2005-03-13 19:04:41 +00:00
|
|
|
}
|
|
|
|
|
2007-02-14 05:52:17 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// TargetAlignElem, TargetAlign support
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
TargetAlignElem
|
|
|
|
TargetAlignElem::get(AlignTypeEnum align_type, unsigned char abi_align,
|
2007-02-19 22:35:00 +00:00
|
|
|
unsigned char pref_align, uint32_t bit_width) {
|
2007-02-14 05:52:17 +00:00
|
|
|
TargetAlignElem retval;
|
|
|
|
retval.AlignType = align_type;
|
|
|
|
retval.ABIAlign = abi_align;
|
|
|
|
retval.PrefAlign = pref_align;
|
|
|
|
retval.TypeBitWidth = bit_width;
|
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
2007-02-15 02:11:06 +00:00
|
|
|
TargetAlignElem::operator==(const TargetAlignElem &rhs) const {
|
2007-02-14 05:52:17 +00:00
|
|
|
return (AlignType == rhs.AlignType
|
|
|
|
&& ABIAlign == rhs.ABIAlign
|
|
|
|
&& PrefAlign == rhs.PrefAlign
|
|
|
|
&& TypeBitWidth == rhs.TypeBitWidth);
|
|
|
|
}
|
|
|
|
|
|
|
|
std::ostream &
|
2007-02-15 02:11:06 +00:00
|
|
|
TargetAlignElem::dump(std::ostream &os) const {
|
2007-02-14 05:52:17 +00:00
|
|
|
return os << AlignType
|
|
|
|
<< TypeBitWidth
|
|
|
|
<< ":" << (int) (ABIAlign * 8)
|
|
|
|
<< ":" << (int) (PrefAlign * 8);
|
|
|
|
}
|
|
|
|
|
|
|
|
const TargetAlignElem TargetData::InvalidAlignmentElem =
|
|
|
|
TargetAlignElem::get((AlignTypeEnum) -1, 0, 0, 0);
|
|
|
|
|
2001-08-27 16:00:15 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// TargetData Class Implementation
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2007-02-14 05:52:17 +00:00
|
|
|
/*!
|
|
|
|
A TargetDescription string consists of a sequence of hyphen-delimited
|
|
|
|
specifiers for target endianness, pointer size and alignments, and various
|
|
|
|
primitive type sizes and alignments. A typical string looks something like:
|
2007-02-15 02:11:06 +00:00
|
|
|
<br><br>
|
2007-02-14 05:52:17 +00:00
|
|
|
"E-p:32:32:32-i1:8:8-i8:8:8-i32:32:32-i64:32:64-f32:32:32-f64:32:64"
|
2007-02-15 02:11:06 +00:00
|
|
|
<br><br>
|
2007-02-14 05:52:17 +00:00
|
|
|
(note: this string is not fully specified and is only an example.)
|
|
|
|
\p
|
|
|
|
Alignments come in two flavors: ABI and preferred. ABI alignment (abi_align,
|
|
|
|
below) dictates how a type will be aligned within an aggregate and when used
|
|
|
|
as an argument. Preferred alignment (pref_align, below) determines a type's
|
|
|
|
alignment when emitted as a global.
|
|
|
|
\p
|
|
|
|
Specifier string details:
|
|
|
|
<br><br>
|
|
|
|
<i>[E|e]</i>: Endianness. "E" specifies a big-endian target data model, "e"
|
|
|
|
specifies a little-endian target data model.
|
|
|
|
<br><br>
|
2007-08-05 20:06:04 +00:00
|
|
|
<i>p:@verbatim<size>:<abi_align>:<pref_align>@endverbatim</i>: Pointer size,
|
|
|
|
ABI and preferred alignment.
|
2007-02-14 05:52:17 +00:00
|
|
|
<br><br>
|
2007-08-05 20:06:04 +00:00
|
|
|
<i>@verbatim<type><size>:<abi_align>:<pref_align>@endverbatim</i>: Numeric type alignment. Type is
|
2007-02-14 05:52:17 +00:00
|
|
|
one of <i>i|f|v|a</i>, corresponding to integer, floating point, vector (aka
|
|
|
|
packed) or aggregate. Size indicates the size, e.g., 32 or 64 bits.
|
|
|
|
\p
|
|
|
|
The default string, fully specified is:
|
|
|
|
<br><br>
|
|
|
|
"E-p:64:64:64-a0:0:0-f32:32:32-f64:0:64"
|
|
|
|
"-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:0:64"
|
|
|
|
"-v64:64:64-v128:128:128"
|
|
|
|
<br><br>
|
|
|
|
Note that in the case of aggregates, 0 is the default ABI and preferred
|
|
|
|
alignment. This is a special case, where the aggregate's computed worst-case
|
|
|
|
alignment will be used.
|
|
|
|
*/
|
2006-06-16 18:11:26 +00:00
|
|
|
void TargetData::init(const std::string &TargetDescription) {
|
2006-05-12 05:49:47 +00:00
|
|
|
std::string temp = TargetDescription;
|
|
|
|
|
|
|
|
LittleEndian = false;
|
2007-01-20 22:35:55 +00:00
|
|
|
PointerMemSize = 8;
|
2007-02-14 05:52:17 +00:00
|
|
|
PointerABIAlign = 8;
|
|
|
|
PointerPrefAlign = PointerABIAlign;
|
|
|
|
|
|
|
|
// Default alignments
|
2007-02-15 02:11:06 +00:00
|
|
|
setAlignment(INTEGER_ALIGN, 1, 1, 1); // Bool
|
|
|
|
setAlignment(INTEGER_ALIGN, 1, 1, 8); // Byte
|
|
|
|
setAlignment(INTEGER_ALIGN, 2, 2, 16); // short
|
|
|
|
setAlignment(INTEGER_ALIGN, 4, 4, 32); // int
|
|
|
|
setAlignment(INTEGER_ALIGN, 4, 8, 64); // long
|
|
|
|
setAlignment(FLOAT_ALIGN, 4, 4, 32); // float
|
|
|
|
setAlignment(FLOAT_ALIGN, 8, 8, 64); // double
|
2007-02-15 22:07:05 +00:00
|
|
|
setAlignment(VECTOR_ALIGN, 8, 8, 64); // v2i32
|
|
|
|
setAlignment(VECTOR_ALIGN, 16, 16, 128); // v16i8, v8i16, v4i32, ...
|
2007-02-16 23:11:51 +00:00
|
|
|
setAlignment(AGGREGATE_ALIGN, 0, 8, 0); // struct, union, class, ...
|
2007-09-07 14:52:14 +00:00
|
|
|
|
2006-05-20 00:24:56 +00:00
|
|
|
while (!temp.empty()) {
|
2006-05-12 05:49:47 +00:00
|
|
|
std::string token = getToken(temp, "-");
|
2007-02-14 05:52:17 +00:00
|
|
|
std::string arg0 = getToken(token, ":");
|
|
|
|
const char *p = arg0.c_str();
|
|
|
|
switch(*p) {
|
2006-05-12 05:49:47 +00:00
|
|
|
case 'E':
|
2006-05-12 06:06:55 +00:00
|
|
|
LittleEndian = false;
|
|
|
|
break;
|
2006-05-12 05:49:47 +00:00
|
|
|
case 'e':
|
2006-05-12 06:06:55 +00:00
|
|
|
LittleEndian = true;
|
|
|
|
break;
|
2006-05-12 05:49:47 +00:00
|
|
|
case 'p':
|
2007-01-20 22:35:55 +00:00
|
|
|
PointerMemSize = atoi(getToken(token,":").c_str()) / 8;
|
2007-02-14 05:52:17 +00:00
|
|
|
PointerABIAlign = atoi(getToken(token,":").c_str()) / 8;
|
|
|
|
PointerPrefAlign = atoi(getToken(token,":").c_str()) / 8;
|
|
|
|
if (PointerPrefAlign == 0)
|
|
|
|
PointerPrefAlign = PointerABIAlign;
|
2006-05-12 06:06:55 +00:00
|
|
|
break;
|
2006-05-12 05:49:47 +00:00
|
|
|
case 'i':
|
2007-02-14 05:52:17 +00:00
|
|
|
case 'v':
|
|
|
|
case 'f':
|
2007-09-07 14:52:14 +00:00
|
|
|
case 'a':
|
|
|
|
case 's': {
|
2007-11-09 19:06:14 +00:00
|
|
|
AlignTypeEnum align_type = STACK_ALIGN; // Dummy init, silence warning
|
2007-09-07 14:52:14 +00:00
|
|
|
switch(*p) {
|
|
|
|
case 'i': align_type = INTEGER_ALIGN; break;
|
|
|
|
case 'v': align_type = VECTOR_ALIGN; break;
|
|
|
|
case 'f': align_type = FLOAT_ALIGN; break;
|
|
|
|
case 'a': align_type = AGGREGATE_ALIGN; break;
|
|
|
|
case 's': align_type = STACK_ALIGN; break;
|
|
|
|
}
|
2007-02-19 23:30:10 +00:00
|
|
|
uint32_t size = (uint32_t) atoi(++p);
|
|
|
|
unsigned char abi_align = atoi(getToken(token, ":").c_str()) / 8;
|
|
|
|
unsigned char pref_align = atoi(getToken(token, ":").c_str()) / 8;
|
2007-02-14 05:52:17 +00:00
|
|
|
if (pref_align == 0)
|
|
|
|
pref_align = abi_align;
|
|
|
|
setAlignment(align_type, abi_align, pref_align, size);
|
2006-05-12 06:06:55 +00:00
|
|
|
break;
|
2007-02-14 05:52:17 +00:00
|
|
|
}
|
2006-05-12 05:49:47 +00:00
|
|
|
default:
|
2006-05-12 06:06:55 +00:00
|
|
|
break;
|
2006-05-12 05:49:47 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-05-01 21:15:47 +00:00
|
|
|
TargetData::TargetData(const Module *M)
|
|
|
|
: ImmutablePass((intptr_t)&ID) {
|
2007-01-26 08:11:39 +00:00
|
|
|
init(M->getDataLayout());
|
2003-04-24 19:09:05 +00:00
|
|
|
}
|
|
|
|
|
2007-02-14 05:52:17 +00:00
|
|
|
void
|
|
|
|
TargetData::setAlignment(AlignTypeEnum align_type, unsigned char abi_align,
|
2007-02-19 22:35:00 +00:00
|
|
|
unsigned char pref_align, uint32_t bit_width) {
|
2007-02-17 00:41:42 +00:00
|
|
|
for (unsigned i = 0, e = Alignments.size(); i != e; ++i) {
|
|
|
|
if (Alignments[i].AlignType == align_type &&
|
|
|
|
Alignments[i].TypeBitWidth == bit_width) {
|
|
|
|
// Update the abi, preferred alignments.
|
|
|
|
Alignments[i].ABIAlign = abi_align;
|
|
|
|
Alignments[i].PrefAlign = pref_align;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
Alignments.push_back(TargetAlignElem::get(align_type, abi_align,
|
|
|
|
pref_align, bit_width));
|
2007-02-14 05:52:17 +00:00
|
|
|
}
|
|
|
|
|
2007-02-17 00:41:42 +00:00
|
|
|
/// getAlignmentInfo - Return the alignment (either ABI if ABIInfo = true or
|
|
|
|
/// preferred if ABIInfo = false) the target wants for the specified datatype.
|
2007-02-19 22:35:00 +00:00
|
|
|
unsigned TargetData::getAlignmentInfo(AlignTypeEnum AlignType,
|
|
|
|
uint32_t BitWidth, bool ABIInfo) const {
|
2007-02-17 00:41:42 +00:00
|
|
|
// Check to see if we have an exact match and remember the best match we see.
|
|
|
|
int BestMatchIdx = -1;
|
2007-02-19 22:35:00 +00:00
|
|
|
int LargestInt = -1;
|
2007-02-17 00:41:42 +00:00
|
|
|
for (unsigned i = 0, e = Alignments.size(); i != e; ++i) {
|
|
|
|
if (Alignments[i].AlignType == AlignType &&
|
|
|
|
Alignments[i].TypeBitWidth == BitWidth)
|
|
|
|
return ABIInfo ? Alignments[i].ABIAlign : Alignments[i].PrefAlign;
|
|
|
|
|
|
|
|
// The best match so far depends on what we're looking for.
|
2007-12-21 20:18:41 +00:00
|
|
|
if (AlignType == VECTOR_ALIGN && Alignments[i].AlignType == VECTOR_ALIGN) {
|
2007-02-17 00:41:42 +00:00
|
|
|
// If this is a specification for a smaller vector type, we will fall back
|
|
|
|
// to it. This happens because <128 x double> can be implemented in terms
|
|
|
|
// of 64 <2 x double>.
|
2007-12-21 20:18:41 +00:00
|
|
|
if (Alignments[i].TypeBitWidth < BitWidth) {
|
2007-02-17 00:41:42 +00:00
|
|
|
// Verify that we pick the biggest of the fallbacks.
|
|
|
|
if (BestMatchIdx == -1 ||
|
2007-12-21 20:18:41 +00:00
|
|
|
Alignments[BestMatchIdx].TypeBitWidth < Alignments[i].TypeBitWidth)
|
2007-02-17 00:41:42 +00:00
|
|
|
BestMatchIdx = i;
|
|
|
|
}
|
2007-02-19 22:35:00 +00:00
|
|
|
} else if (AlignType == INTEGER_ALIGN &&
|
|
|
|
Alignments[i].AlignType == INTEGER_ALIGN) {
|
|
|
|
// The "best match" for integers is the smallest size that is larger than
|
|
|
|
// the BitWidth requested.
|
|
|
|
if (Alignments[i].TypeBitWidth > BitWidth && (BestMatchIdx == -1 ||
|
|
|
|
Alignments[i].TypeBitWidth < Alignments[BestMatchIdx].TypeBitWidth))
|
|
|
|
BestMatchIdx = i;
|
|
|
|
// However, if there isn't one that's larger, then we must use the
|
|
|
|
// largest one we have (see below)
|
|
|
|
if (LargestInt == -1 ||
|
|
|
|
Alignments[i].TypeBitWidth > Alignments[LargestInt].TypeBitWidth)
|
|
|
|
LargestInt = i;
|
2007-02-17 00:41:42 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-02-19 22:35:00 +00:00
|
|
|
// For integers, if we didn't find a best match, use the largest one found.
|
|
|
|
if (BestMatchIdx == -1)
|
|
|
|
BestMatchIdx = LargestInt;
|
|
|
|
|
2007-02-17 00:41:42 +00:00
|
|
|
// Okay, we didn't find an exact solution. Fall back here depending on what
|
|
|
|
// is being looked for.
|
|
|
|
assert(BestMatchIdx != -1 && "Didn't find alignment info for this datatype!");
|
2007-02-19 22:35:00 +00:00
|
|
|
|
|
|
|
// Since we got a "best match" index, just return it.
|
2007-02-17 00:41:42 +00:00
|
|
|
return ABIInfo ? Alignments[BestMatchIdx].ABIAlign
|
|
|
|
: Alignments[BestMatchIdx].PrefAlign;
|
2007-02-14 05:52:17 +00:00
|
|
|
}
|
|
|
|
|
2007-02-10 19:43:18 +00:00
|
|
|
/// LayoutInfo - The lazy cache of structure layout information maintained by
|
2007-02-10 20:15:41 +00:00
|
|
|
/// TargetData. Note that the struct types must have been free'd before
|
|
|
|
/// llvm_shutdown is called (and thus this is deallocated) because all the
|
|
|
|
/// targets with cached elements should have been destroyed.
|
2006-01-14 00:07:34 +00:00
|
|
|
///
|
2007-02-10 19:43:18 +00:00
|
|
|
typedef std::pair<const TargetData*,const StructType*> LayoutKey;
|
2007-02-10 20:26:17 +00:00
|
|
|
|
|
|
|
struct DenseMapLayoutKeyInfo {
|
|
|
|
static inline LayoutKey getEmptyKey() { return LayoutKey(0, 0); }
|
|
|
|
static inline LayoutKey getTombstoneKey() {
|
|
|
|
return LayoutKey((TargetData*)(intptr_t)-1, 0);
|
|
|
|
}
|
|
|
|
static unsigned getHashValue(const LayoutKey &Val) {
|
2007-09-17 18:34:04 +00:00
|
|
|
return DenseMapInfo<void*>::getHashValue(Val.first) ^
|
|
|
|
DenseMapInfo<void*>::getHashValue(Val.second);
|
2007-02-10 20:26:17 +00:00
|
|
|
}
|
2007-09-17 18:34:04 +00:00
|
|
|
static bool isEqual(const LayoutKey &LHS, const LayoutKey &RHS) {
|
|
|
|
return LHS == RHS;
|
|
|
|
}
|
|
|
|
|
2007-02-10 20:26:17 +00:00
|
|
|
static bool isPod() { return true; }
|
|
|
|
};
|
|
|
|
|
|
|
|
typedef DenseMap<LayoutKey, StructLayout*, DenseMapLayoutKeyInfo> LayoutInfoTy;
|
2007-02-10 20:18:06 +00:00
|
|
|
static ManagedStatic<LayoutInfoTy> LayoutInfo;
|
2004-02-26 08:02:17 +00:00
|
|
|
|
|
|
|
|
2001-08-27 16:00:15 +00:00
|
|
|
TargetData::~TargetData() {
|
2007-02-10 19:43:18 +00:00
|
|
|
if (LayoutInfo.isConstructed()) {
|
2004-02-26 08:02:17 +00:00
|
|
|
// Remove any layouts for this TD.
|
2007-02-10 20:18:06 +00:00
|
|
|
LayoutInfoTy &TheMap = *LayoutInfo;
|
2007-02-10 20:26:17 +00:00
|
|
|
for (LayoutInfoTy::iterator I = TheMap.begin(), E = TheMap.end();
|
|
|
|
I != E; ) {
|
|
|
|
if (I->first.first == this) {
|
|
|
|
I->second->~StructLayout();
|
|
|
|
free(I->second);
|
|
|
|
TheMap.erase(I++);
|
|
|
|
} else {
|
|
|
|
++I;
|
|
|
|
}
|
2007-02-10 20:15:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
const StructLayout *TargetData::getStructLayout(const StructType *Ty) const {
|
2007-02-10 20:18:06 +00:00
|
|
|
LayoutInfoTy &TheMap = *LayoutInfo;
|
2007-02-10 20:15:41 +00:00
|
|
|
|
2007-02-10 20:26:17 +00:00
|
|
|
StructLayout *&SL = TheMap[LayoutKey(this, Ty)];
|
|
|
|
if (SL) return SL;
|
2007-02-10 20:15:41 +00:00
|
|
|
|
|
|
|
// Otherwise, create the struct layout. Because it is variable length, we
|
|
|
|
// malloc it, then use placement new.
|
2007-04-09 19:26:30 +00:00
|
|
|
int NumElts = Ty->getNumElements();
|
2007-02-10 20:15:41 +00:00
|
|
|
StructLayout *L =
|
|
|
|
(StructLayout *)malloc(sizeof(StructLayout)+(NumElts-1)*sizeof(uint64_t));
|
2007-02-10 20:26:17 +00:00
|
|
|
|
|
|
|
// Set SL before calling StructLayout's ctor. The ctor could cause other
|
|
|
|
// entries to be added to TheMap, invalidating our reference.
|
|
|
|
SL = L;
|
|
|
|
|
2007-02-10 20:15:41 +00:00
|
|
|
new (L) StructLayout(Ty, *this);
|
|
|
|
return L;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// InvalidateStructLayoutInfo - TargetData speculatively caches StructLayout
|
|
|
|
/// objects. If a TargetData object is alive when types are being refined and
|
|
|
|
/// removed, this method must be called whenever a StructType is removed to
|
|
|
|
/// avoid a dangling pointer in this cache.
|
|
|
|
void TargetData::InvalidateStructLayoutInfo(const StructType *Ty) const {
|
|
|
|
if (!LayoutInfo.isConstructed()) return; // No cache.
|
|
|
|
|
2007-02-10 20:18:06 +00:00
|
|
|
LayoutInfoTy::iterator I = LayoutInfo->find(LayoutKey(this, Ty));
|
2007-02-10 20:15:41 +00:00
|
|
|
if (I != LayoutInfo->end()) {
|
|
|
|
I->second->~StructLayout();
|
|
|
|
free(I->second);
|
|
|
|
LayoutInfo->erase(I);
|
2004-02-26 08:02:17 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-02-10 20:15:41 +00:00
|
|
|
|
2006-05-12 07:01:44 +00:00
|
|
|
std::string TargetData::getStringRepresentation() const {
|
2007-02-15 02:11:06 +00:00
|
|
|
std::string repr;
|
|
|
|
repr.append(LittleEndian ? "e" : "E");
|
|
|
|
repr.append("-p:").append(itostr((int64_t) (PointerMemSize * 8))).
|
|
|
|
append(":").append(itostr((int64_t) (PointerABIAlign * 8))).
|
|
|
|
append(":").append(itostr((int64_t) (PointerPrefAlign * 8)));
|
|
|
|
for (align_const_iterator I = Alignments.begin();
|
|
|
|
I != Alignments.end();
|
|
|
|
++I) {
|
|
|
|
repr.append("-").append(1, (char) I->AlignType).
|
|
|
|
append(utostr((int64_t) I->TypeBitWidth)).
|
|
|
|
append(":").append(utostr((uint64_t) (I->ABIAlign * 8))).
|
|
|
|
append(":").append(utostr((uint64_t) (I->PrefAlign * 8)));
|
|
|
|
}
|
|
|
|
return repr;
|
2006-05-12 07:01:44 +00:00
|
|
|
}
|
|
|
|
|
2006-01-14 00:07:34 +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 TargetData::getTypeSizeInBits(const Type *Ty) const {
|
2001-12-13 00:46:11 +00:00
|
|
|
assert(Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!");
|
2004-06-17 18:19:28 +00:00
|
|
|
switch (Ty->getTypeID()) {
|
2001-08-27 16:00:15 +00:00
|
|
|
case Type::LabelTyID:
|
|
|
|
case Type::PointerTyID:
|
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 getPointerSizeInBits();
|
2001-08-27 16:00:15 +00:00
|
|
|
case Type::ArrayTyID: {
|
2004-07-01 17:32:59 +00:00
|
|
|
const ArrayType *ATy = cast<ArrayType>(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
|
|
|
return getABITypeSizeInBits(ATy->getElementType())*ATy->getNumElements();
|
2004-12-01 17:14:28 +00:00
|
|
|
}
|
2001-08-27 16:00:15 +00:00
|
|
|
case Type::StructTyID: {
|
|
|
|
// Get the layout annotation... which is lazily created on demand.
|
2007-02-14 05:52:17 +00:00
|
|
|
const StructLayout *Layout = getStructLayout(cast<StructType>(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
|
|
|
return Layout->getSizeInBits();
|
2007-01-20 22:35:55 +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
|
|
|
case Type::IntegerTyID:
|
|
|
|
return cast<IntegerType>(Ty)->getBitWidth();
|
2007-01-20 22:35:55 +00:00
|
|
|
case Type::VoidTyID:
|
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;
|
2007-01-20 22:35:55 +00:00
|
|
|
case Type::FloatTyID:
|
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 32;
|
2007-01-20 22:35:55 +00:00
|
|
|
case Type::DoubleTyID:
|
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 64;
|
2007-08-03 20:20:50 +00:00
|
|
|
case Type::PPC_FP128TyID:
|
|
|
|
case Type::FP128TyID:
|
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 128;
|
2007-08-03 20:20:50 +00:00
|
|
|
// In memory objects this is always aligned to a higher boundary, but
|
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
|
|
|
// only 80 bits contain information.
|
2007-08-03 20:20:50 +00:00
|
|
|
case Type::X86_FP80TyID:
|
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 80;
|
2007-02-15 02:26:10 +00:00
|
|
|
case Type::VectorTyID: {
|
|
|
|
const VectorType *PTy = cast<VectorType>(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
|
|
|
return PTy->getBitWidth();
|
2007-01-20 22:35:55 +00:00
|
|
|
}
|
|
|
|
default:
|
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
|
|
|
assert(0 && "TargetData::getTypeSizeInBits(): Unsupported type");
|
2007-02-14 05:52:17 +00:00
|
|
|
break;
|
2007-01-20 22:35:55 +00:00
|
|
|
}
|
2007-02-14 05:52:17 +00:00
|
|
|
return 0;
|
2001-08-27 16:00:15 +00:00
|
|
|
}
|
|
|
|
|
2007-02-14 05:52:17 +00:00
|
|
|
/*!
|
|
|
|
\param abi_or_pref Flag that determines which alignment is returned. true
|
|
|
|
returns the ABI alignment, false returns the preferred alignment.
|
|
|
|
\param Ty The underlying type for which alignment is determined.
|
|
|
|
|
|
|
|
Get the ABI (\a abi_or_pref == true) or preferred alignment (\a abi_or_pref
|
|
|
|
== false) for the requested type \a Ty.
|
|
|
|
*/
|
2007-02-16 22:25:34 +00:00
|
|
|
unsigned char TargetData::getAlignment(const Type *Ty, bool abi_or_pref) const {
|
2007-02-14 05:52:17 +00:00
|
|
|
int AlignType = -1;
|
|
|
|
|
|
|
|
assert(Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!");
|
|
|
|
switch (Ty->getTypeID()) {
|
|
|
|
/* Early escape for the non-numeric types */
|
|
|
|
case Type::LabelTyID:
|
|
|
|
case Type::PointerTyID:
|
|
|
|
return (abi_or_pref
|
|
|
|
? getPointerABIAlignment()
|
|
|
|
: getPointerPrefAlignment());
|
2007-02-16 22:25:34 +00:00
|
|
|
case Type::ArrayTyID:
|
|
|
|
return getAlignment(cast<ArrayType>(Ty)->getElementType(), abi_or_pref);
|
|
|
|
|
2007-02-14 05:52:17 +00:00
|
|
|
case Type::StructTyID: {
|
2007-02-16 22:25:34 +00:00
|
|
|
// Packed structure types always have an ABI alignment of one.
|
2007-02-16 23:11:51 +00:00
|
|
|
if (cast<StructType>(Ty)->isPacked() && abi_or_pref)
|
2007-02-16 22:25:34 +00:00
|
|
|
return 1;
|
|
|
|
|
|
|
|
// Get the layout annotation... which is lazily created on demand.
|
2007-02-14 05:52:17 +00:00
|
|
|
const StructLayout *Layout = getStructLayout(cast<StructType>(Ty));
|
2007-02-17 00:41:42 +00:00
|
|
|
unsigned Align = getAlignmentInfo(AGGREGATE_ALIGN, 0, abi_or_pref);
|
|
|
|
return std::max(Align, (unsigned)Layout->getAlignment());
|
2007-02-14 05:52:17 +00:00
|
|
|
}
|
|
|
|
case Type::IntegerTyID:
|
|
|
|
case Type::VoidTyID:
|
|
|
|
AlignType = INTEGER_ALIGN;
|
|
|
|
break;
|
|
|
|
case Type::FloatTyID:
|
|
|
|
case Type::DoubleTyID:
|
2007-08-03 20:20:50 +00:00
|
|
|
// PPC_FP128TyID and FP128TyID have different data contents, but the
|
|
|
|
// same size and alignment, so they look the same here.
|
|
|
|
case Type::PPC_FP128TyID:
|
|
|
|
case Type::FP128TyID:
|
|
|
|
case Type::X86_FP80TyID:
|
2007-02-14 05:52:17 +00:00
|
|
|
AlignType = FLOAT_ALIGN;
|
|
|
|
break;
|
2007-04-22 21:54:13 +00:00
|
|
|
case Type::VectorTyID: {
|
|
|
|
const VectorType *VTy = cast<VectorType>(Ty);
|
|
|
|
// Degenerate vectors are assumed to be scalar-ized
|
|
|
|
if (VTy->getNumElements() == 1)
|
|
|
|
return getAlignment(VTy->getElementType(), abi_or_pref);
|
|
|
|
else
|
|
|
|
AlignType = VECTOR_ALIGN;
|
2007-02-14 05:52:17 +00:00
|
|
|
break;
|
2007-04-22 21:54:13 +00:00
|
|
|
}
|
2007-02-14 05:52:17 +00:00
|
|
|
default:
|
|
|
|
assert(0 && "Bad type for getAlignment!!!");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
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 getAlignmentInfo((AlignTypeEnum)AlignType, getTypeSizeInBits(Ty),
|
2007-02-17 00:41:42 +00:00
|
|
|
abi_or_pref);
|
2007-01-20 23:32:04 +00:00
|
|
|
}
|
|
|
|
|
2007-02-14 05:52:17 +00:00
|
|
|
unsigned char TargetData::getABITypeAlignment(const Type *Ty) const {
|
|
|
|
return getAlignment(Ty, true);
|
2007-01-20 22:35:55 +00:00
|
|
|
}
|
|
|
|
|
2007-09-07 14:52:14 +00:00
|
|
|
unsigned char TargetData::getCallFrameTypeAlignment(const Type *Ty) const {
|
|
|
|
for (unsigned i = 0, e = Alignments.size(); i != e; ++i)
|
|
|
|
if (Alignments[i].AlignType == STACK_ALIGN)
|
|
|
|
return Alignments[i].ABIAlign;
|
|
|
|
|
|
|
|
return getABITypeAlignment(Ty);
|
|
|
|
}
|
|
|
|
|
2007-02-14 05:52:17 +00:00
|
|
|
unsigned char TargetData::getPrefTypeAlignment(const Type *Ty) const {
|
|
|
|
return getAlignment(Ty, false);
|
2001-08-27 16:00:15 +00:00
|
|
|
}
|
|
|
|
|
2007-01-24 07:03:39 +00:00
|
|
|
unsigned char TargetData::getPreferredTypeAlignmentShift(const Type *Ty) const {
|
2007-02-14 05:52:17 +00:00
|
|
|
unsigned Align = (unsigned) getPrefTypeAlignment(Ty);
|
2004-08-17 19:13:00 +00:00
|
|
|
assert(!(Align & (Align-1)) && "Alignment is not a power of two!");
|
2005-08-02 19:26:06 +00:00
|
|
|
return Log2_32(Align);
|
2004-08-17 19:13:00 +00:00
|
|
|
}
|
|
|
|
|
2003-12-22 05:01:15 +00:00
|
|
|
/// getIntPtrType - Return an unsigned integer type that is the same size or
|
|
|
|
/// greater to the host pointer size.
|
|
|
|
const Type *TargetData::getIntPtrType() const {
|
2007-10-08 15:16:25 +00:00
|
|
|
return IntegerType::get(getPointerSizeInBits());
|
2003-12-22 05:01:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2007-02-10 19:33:15 +00:00
|
|
|
uint64_t TargetData::getIndexedOffset(const Type *ptrTy, Value* const* Indices,
|
|
|
|
unsigned NumIndices) const {
|
2002-08-04 20:52:39 +00:00
|
|
|
const Type *Ty = ptrTy;
|
|
|
|
assert(isa<PointerType>(Ty) && "Illegal argument for getIndexedOffset()");
|
2002-05-19 15:28:02 +00:00
|
|
|
uint64_t Result = 0;
|
|
|
|
|
2007-02-10 19:33:15 +00:00
|
|
|
generic_gep_type_iterator<Value* const*>
|
|
|
|
TI = gep_type_begin(ptrTy, Indices, Indices+NumIndices);
|
|
|
|
for (unsigned CurIDX = 0; CurIDX != NumIndices; ++CurIDX, ++TI) {
|
2004-04-05 01:30:19 +00:00
|
|
|
if (const StructType *STy = dyn_cast<StructType>(*TI)) {
|
2007-03-01 19:48:16 +00:00
|
|
|
assert(Indices[CurIDX]->getType() == Type::Int32Ty &&
|
|
|
|
"Illegal struct idx");
|
2007-02-10 19:33:15 +00:00
|
|
|
unsigned FieldNo = cast<ConstantInt>(Indices[CurIDX])->getZExtValue();
|
2001-08-27 16:00:15 +00:00
|
|
|
|
|
|
|
// Get structure layout information...
|
|
|
|
const StructLayout *Layout = getStructLayout(STy);
|
|
|
|
|
|
|
|
// Add in the offset, as calculated by the structure layout info...
|
2007-02-10 19:55:17 +00:00
|
|
|
Result += Layout->getElementOffset(FieldNo);
|
2002-08-04 20:52:39 +00:00
|
|
|
|
2001-08-27 16:00:15 +00:00
|
|
|
// Update Ty to refer to current element
|
2004-02-09 04:37:31 +00:00
|
|
|
Ty = STy->getElementType(FieldNo);
|
2004-04-05 01:30:19 +00:00
|
|
|
} else {
|
|
|
|
// Update Ty to refer to current element
|
|
|
|
Ty = cast<SequentialType>(Ty)->getElementType();
|
|
|
|
|
|
|
|
// Get the array index and the size of each array element.
|
2007-02-10 19:33:15 +00:00
|
|
|
int64_t arrayIdx = cast<ConstantInt>(Indices[CurIDX])->getSExtValue();
|
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
|
|
|
Result += arrayIdx * (int64_t)getABITypeSize(Ty);
|
2001-08-27 16:00:15 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return Result;
|
|
|
|
}
|
2003-11-11 22:41:34 +00:00
|
|
|
|
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).
|
|
|
|
unsigned TargetData::getPreferredAlignmentLog(const GlobalVariable *GV) const {
|
|
|
|
const Type *ElemType = GV->getType()->getElementType();
|
2007-01-24 07:03:39 +00:00
|
|
|
unsigned Alignment = getPreferredTypeAlignmentShift(ElemType);
|
2006-10-24 20:32:14 +00:00
|
|
|
if (GV->getAlignment() > (1U << Alignment))
|
|
|
|
Alignment = Log2_32(GV->getAlignment());
|
|
|
|
|
|
|
|
if (GV->hasInitializer()) {
|
|
|
|
if (Alignment < 4) {
|
|
|
|
// If the global is not external, see if it is large. If so, give it a
|
|
|
|
// larger alignment.
|
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
|
|
|
if (getTypeSizeInBits(ElemType) > 128)
|
2006-10-24 20:32:14 +00:00
|
|
|
Alignment = 4; // 16-byte alignment.
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return Alignment;
|
|
|
|
}
|