llvm-svn: 51955

llvm-svn: 51954

llvm-svn: 51953

ability to handle indirect input operands.  This fixes PR2407.

llvm-svn: 51952

Correctly construct live intervals for the copies we inserted into the predecessors of a block containing a PHI.

llvm-svn: 51950

llvm-svn: 51949

llvm-svn: 51947

Add CallSite::hasArgument to allow for seeing if a call passes a certain value as an argument quickly.

llvm-svn: 51946

Add a Name parameter to two of the init methods of GetElementPointer to make the name setting more consistent.

llvm-svn: 51945

llvm-svn: 51942

Add a Name argment to two init methods in these classes as well to make things
a bit more consistent.

llvm-svn: 51937

llvm-svn: 51934

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