aboutsummaryrefslogtreecommitdiffstats
path: root/lib/Target/TargetData.cpp
diff options
context:
space:
mode:
authorDan Gohman <gohman@apple.com>2010-02-25 15:20:39 +0000
committerDan Gohman <gohman@apple.com>2010-02-25 15:20:39 +0000
commitaa9d854b334cab2f29ca6d95413a0946b8a38429 (patch)
treecea0953c05223188ec4fb31bfc0a915b83c2b5b1 /lib/Target/TargetData.cpp
parent9a49f1552db7e2ce24a03ec068b17db8a238856d (diff)
downloadexternal_llvm-aa9d854b334cab2f29ca6d95413a0946b8a38429.zip
external_llvm-aa9d854b334cab2f29ca6d95413a0946b8a38429.tar.gz
external_llvm-aa9d854b334cab2f29ca6d95413a0946b8a38429.tar.bz2
Revert r97064. Duncan pointed out that bitcasts are defined in
terms of store and load, which means bitcasting between scalar integer and vector has endian-specific results, which undermines this whole approach. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97137 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'lib/Target/TargetData.cpp')
-rw-r--r--lib/Target/TargetData.cpp43
1 files changed, 1 insertions, 42 deletions
diff --git a/lib/Target/TargetData.cpp b/lib/Target/TargetData.cpp
index 2a90d7f..9a16808 100644
--- a/lib/Target/TargetData.cpp
+++ b/lib/Target/TargetData.cpp
@@ -455,7 +455,7 @@ uint64_t TargetData::getTypeSizeInBits(const Type *Ty) const {
return getPointerSizeInBits();
case Type::ArrayTyID: {
const ArrayType *ATy = cast<ArrayType>(Ty);
- return getTypeSizeInBits(ATy->getElementType())*ATy->getNumElements();
+ return getTypeAllocSizeInBits(ATy->getElementType())*ATy->getNumElements();
}
case Type::StructTyID:
// Get the layout annotation... which is lazily created on demand.
@@ -484,47 +484,6 @@ uint64_t TargetData::getTypeSizeInBits(const Type *Ty) const {
return 0;
}
-/// getTypeStoreSize - Return the maximum number of bytes that may be
-/// overwritten by storing the specified type. For example, returns 5
-/// for i36 and 10 for x86_fp80.
-uint64_t TargetData::getTypeStoreSize(const Type *Ty) const {
- // Arrays and vectors are allocated as sequences of elements.
- if (const ArrayType *ATy = dyn_cast<ArrayType>(Ty)) {
- if (ATy->getNumElements() == 0)
- return 0;
- const Type *ElementType = ATy->getElementType();
- return getTypeAllocSize(ElementType) * (ATy->getNumElements() - 1) +
- getTypeStoreSize(ElementType);
- }
- if (const VectorType *VTy = dyn_cast<VectorType>(Ty)) {
- const Type *ElementType = VTy->getElementType();
- return getTypeAllocSize(ElementType) * (VTy->getNumElements() - 1) +
- getTypeStoreSize(ElementType);
- }
-
- return (getTypeSizeInBits(Ty)+7)/8;
-}
-
-/// getTypeAllocSize - Return the offset in bytes between successive objects
-/// of the specified type, including alignment padding. This is the amount
-/// that alloca reserves for this type. For example, returns 12 or 16 for
-/// x86_fp80, depending on alignment.
-uint64_t TargetData::getTypeAllocSize(const Type* Ty) const {
- // Arrays and vectors are allocated as sequences of elements.
- // Note that this means that things like vectors-of-i1 are not bit-packed
- // in memory (except on a hypothetical bit-addressable machine). If
- // someone builds hardware with native vector-of-i1 stores and the idiom
- // of bitcasting vectors to integers in order to bitpack them for storage
- // isn't sufficient, TargetData may need new "size" concept.
- if (const ArrayType *ATy = dyn_cast<ArrayType>(Ty))
- return getTypeAllocSize(ATy->getElementType()) * ATy->getNumElements();
- if (const VectorType *VTy = dyn_cast<VectorType>(Ty))
- return getTypeAllocSize(VTy->getElementType()) * VTy->getNumElements();
-
- // Round up to the next alignment boundary.
- return RoundUpAlignment(getTypeStoreSize(Ty), getABITypeAlignment(Ty));
-}
-
/*!
\param abi_or_pref Flag that determines which alignment is returned. true
returns the ABI alignment, false returns the preferred alignment.