llvm-svn: 51933

llvm-svn: 51932

llvm-svn: 51931

llvm-svn: 51930

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

for reporting this.

llvm-svn: 51926

Added support for mips little endian arch => mipsel

llvm-svn: 51923

llvm-svn: 51922

llvm-svn: 51917

llvm-svn: 51916

Don't crash when we encounter one of these.

llvm-svn: 51915

llvm-svn: 51911

llvm-svn: 51910

assembler names of string constants look like.

llvm-svn: 51909

llvm-svn: 51904

the solution commited is different from the previous patch to
avoid int and unsigned comparison

llvm-svn: 51899

llvm-svn: 51898

llvm-svn: 51897

llvm-svn: 51893

"Unable to handle Pass that requires lower level Analysis pass"

llvm-svn: 51892

llvm-svn: 51891

llvm-svn: 51890

llvm-svn: 51889

llvm-svn: 51887

for dagcombine to do this.

llvm-svn: 51886

constant shows up in the assembly language output. Helps with
debugging without a HP calculator having to be handy.

llvm-svn: 51885

issue is operand promotion for setcc/select... but looks like the fundamental
stuff is implemented for CellSPU.

llvm-svn: 51884

and insertvalue and extractvalue instructions.

First-class array values are not trivial because C doesn't
support them. The approach I took here is to wrap all arrays
in structs. Feedback is welcome.

The 2007-01-15-NamedArrayType.ll test needed to be modified
because it has a "not grep" for a string that now exists,
because array types now have associated struct types, and
those struct types have names.

llvm-svn: 51881

llvm-svn: 51879

llvm-svn: 51878

in DAGISelEmitter output. This bug was recently uncovered by the
addition of patterns for CALL32m and CALL64m, which are nodes
that now have both MemOperands and variadic_ops.

This bug was especially visible with PIC in various configurations,
because the new patterns are matching the indirect call code used
in many PIC configurations.

llvm-svn: 51877

llvm-svn: 51876

is longer than the second one) should stop after finding one. Added break 
instruction guarantees it. It also changes difference between offsets to 
absolute value of this difference in the condition.

llvm-svn: 51875

hash_map/hash_set/iterator to have a .h suffix.

llvm-svn: 51867

llvm-svn: 51865

llvm-svn: 51864

out of instcombine into a new file in libanalysis.  This also teaches
ComputeNumSignBits about the number of sign bits in a constantint.

llvm-svn: 51863

char a[200];
init(a, a+200);

OR

int a[200];
char* b = (char*)a;
char* c = (char*)a;
foo(b, c);

llvm-svn: 51850

llvm-svn: 51849

llvm-svn: 51848