llvm-svn: 90640

llvm-svn: 90639

llvm-svn: 90588

llvm-svn: 90383

function, converting "dyn_cast" to "cast", asserting the correct things, and
other general cleanups.

llvm-svn: 90371

llvm-svn: 90366

Patch by Howard Hinnant!

llvm-svn: 90365

that it doesn't have dangling pointers when abstract types are resolved. This
modifies it somewhat to address comments: making the "StructLayoutMap" an
anonymous structure, calling "removeAbstractTypeUser" when appropriate, and
adding asserts where helpful.

llvm-svn: 90362

This is probably not confined to *just* these two things.

Anyway, the llvm-gcc front-end may look up the structure layout information for
an abstract type. That information will be stored into a table with the FE's
TD. Instruction combine can come along and also ask for information on that
abstract type, but for a separate TD (the one associated with the pass manager).

After the type is refined, the old structure layout information in the pass
manager's TD file is out of date. If a new type is allocated in the same space
as the old-unrefined type, then the structure type information in the pass
manager's TD file will be wrong, but won't know it.

Fix this by making the TD's structure type information an abstract type user.

llvm-svn: 89176

this gives llvm-gcc generated modules the right data.

llvm-svn: 86435

datatypes on a given CPU.  This is intended to allow instcombine and other
transformations to avoid converting big sequences of operations to an
inconvenient width, and will help clean up after SRoA.  See also "Adding 
legal integer sizes to TargetData" on Feb 1, 2009 on llvmdev, and PR3451.

Comments welcome.

llvm-svn: 86370

llvm-svn: 86369

llvm-svn: 86366

This preserves the existing behavior much more closely than my previous attempt.

llvm-svn: 79663

llvm-svn: 79578

llvm-svn: 79572

U    include/llvm/Target/TargetData.h
U    lib/Target/TargetData.cpp

Temporarily revert 79555. It was causing hangs and test failures.

llvm-svn: 79568

llvm-svn: 79555

llvm-svn: 79532

llvm-svn: 78948

This adds location info for all llvm_unreachable calls (which is a macro now) in
!NDEBUG builds.
In NDEBUG builds location info and the message is off (it only prints
"UREACHABLE executed").

llvm-svn: 75640

Make llvm_unreachable take an optional string, thus moving the cerr<< out of
line.
LLVM_UNREACHABLE is now a simple wrapper that makes the message go away for
NDEBUG builds.

llvm-svn: 75379

llvm-svn: 74931

llvm-svn: 73928

just a Type.

llvm-svn: 71426

will make it more obvious what it represents, and stop
it being confused with the StoreSize.

llvm-svn: 71349

less ambiguous and less C-specific.

llvm-svn: 68219

llvm-svn: 64694

suggested by Chris.

llvm-svn: 62099

llvm-svn: 60755

llvm-svn: 60694

remove some more 64-bit divs and rems from the StructLayout 
ctor.

llvm-svn: 60692

llvm-svn: 55779

are the same as in unpacked structs, only field
positions differ.  This only matters for structs
containing x86 long double or an apint; it may
cause backwards compatibility problems if someone
has bitcode containing a packed struct with a
field of one of those types.
The issue is that only 10 bytes are needed to
hold an x86 long double: the store size is 10
bytes, but the ABI size is 12 or 16 bytes (linux/
darwin) which comes from rounding the store size
up by the alignment.  Because it seemed silly not
to pack an x86 long double into 10 bytes in a
packed struct, this is what was done.  I now
think this was a mistake.  Reserving the ABI size
for an x86 long double field even in a packed
struct makes things more uniform: the ABI size is
now always used when reserving space for a type.
This means that developers are less likely to
make mistakes.  It also makes life easier for the
CBE which otherwise could not represent all LLVM
packed structs (PR2402).
Front-end people might need to adjust the way
they create LLVM structs - see following change
to llvm-gcc.

llvm-svn: 51928

several things that were neither in an anonymous namespace nor static
but not intended to be global.

llvm-svn: 51017

llvm-svn: 49681

llvm-svn: 48554

to get the alignment of global variables, rather than
using hand-made versions.

llvm-svn: 46495

than hardware supported type will be scalarized, so we
can infer their alignment from that info.

We now codegen pr1845 into:

_boolVectorSelect:
	lbz r2, 0(r3)
	stb r2, -16(r1)
	blr 

llvm-svn: 45796

llvm-svn: 45418