Add a new DenseMapInfo::isEqual method to allow clients to redefine
the equality predicate used when probing the hash table.

llvm-svn: 42042

The x86-64 ABI states that objects passed on the stack have
8 byte alignment. Implement that.

llvm-svn: 41768

llvm-svn: 40854

(I've tried to get the info right for all targets,
but I'm not expert on all of them - check yours.)

llvm-svn: 40792

llvm-svn: 36662

Due to darwin gcc bug, one version of darwin linker coalesces
static const int, which defauts PassID based pass identification.

llvm-svn: 36652

llvm-svn: 36648

llvm-svn: 36632

llvm-svn: 36352

Fixes unexpected failures on FreeBSD/amd64 of:
  CFrontend/2005-09-24-BitFieldCrash.c:
  CFrontend/2007-02-04-EmptyStruct.c:
  CFrontend/2007-03-26-ZeroWidthBitfield.c:
  CodeGen/Generic/2005-10-18-ZeroSizeStackObject.ll:

llvm-svn: 35828

llvm-svn: 34917

llvm-svn: 34799

uses them.

llvm-svn: 34432

rules alignment is to pick the alignment that corresponds to the smallest
specified alignment that is larger than the bit width of the type or the
largest specified integer alignment if none are larger than the bitwidth
of the type. For the byte size, the size returned is the next larger
multiple of the alignment for that type (using the above rule). This patch
also changes bit widths from "short" to "uint32_t" to ensure there are
enough bits to specify any bit width that LLVM can handle (currently 2^23);
16-bits isn't enough.

llvm-svn: 34431

This fixes the UnitTests/Vector/sumarray-dbl regressions.

llvm-svn: 34358

llvm-svn: 34356

Patch by Scott Michel.

llvm-svn: 34354

llvm-svn: 34352

PACKED_ALIGN -> VECTOR_ALIGN

llvm-svn: 34330

Make sure we found an existing Alignment before overwriting it.

llvm-svn: 34308

Rename PackedType -> VectorType, ConstantPacked -> ConstantVector, and
PackedTyID -> VectorTyID. No functional changes.

llvm-svn: 34293

Chris Lattner's code style suggestions.

Patch by Scott Michel!

llvm-svn: 34292

Patch by Scott Michel.

llvm-svn: 34266

-load-vn -gcse by 2.3%.

llvm-svn: 34160

llvm-svn: 34159

after the StructLayout object in memory.  This marginally improves locality,
speeding up -load-vn -gcse by ~0.8%.

llvm-svn: 34158

llvm-svn: 34157

llvm-svn: 34156

llvm-svn: 34154

in a vector.

llvm-svn: 34153

must in order for backends that do want to support large integer types to be
able to function. Consequently, don't assert if the bitwidth > 64 bits
when computing the size and alignment. Instead, compute the size by rounding
up to the next even number of bytes for the size. Compute the alignment
as the same as the LongABIAlignment. These provide reasonable defaults
that the target can override.

llvm-svn: 33943

llvm-svn: 33719

The Module::setEndianness and Module::setPointerSize methods have been
removed. Instead you can get/set the DataLayout. Adjust thise accordingly.

llvm-svn: 33530

llvm-svn: 33482

alignment.
- getPreferredAlignmentLog(): remove Double special case.

llvm-svn: 33445

to ensure the bit size of a type is identical before proceeding.

llvm-svn: 33413

an unspecified datatype in the datalayout is capped by the size of a pointer.

llvm-svn: 33411

llvm-svn: 33410

these alignment amounts to align scalars when we can.  Patch by Scott Michel!

llvm-svn: 33409

Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.

This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
   bits in an integer. The Type classes SubclassData field is used to
   store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
   64-bit integers. These are replaced with just IntegerType which is not
   a primitive any more.
3. Adjust the rest of LLVM to account for this change.

Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types.  Future increments
will rectify this situation.

llvm-svn: 33113