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

llvm-svn: 51846

llvm-svn: 51845

llvm-svn: 51842

llvm-svn: 51841

the conditions for performing the transform when only the
function declaration is available: no longer allow turning
i32 into i64 for example.  Only allow changing between
pointer types, and between pointer types and integers of
the same size.  For return values ptr -> intptr was already
allowed; I added ptr -> ptr and intptr -> ptr while there.
As shown by a recent objc testcase, changing the way
parameters/return values are passed can be fatal when calling
code written in assembler that directly manipulates call
arguments and return values unless the transform has no
impact on the way they are passed at the codegen level.
While it is possible to imagine an ABI that treats integers
of pointer size differently to pointers, I don't think LLVM
supports any so the transform should now be safe while still
being useful.

llvm-svn: 51834

llvm-svn: 51833

values, so as to avoid warnings on some platforms.

llvm-svn: 51831

into the 2.3 release branch.

llvm-svn: 51824

now round-trip through assembly and bitcode.

llvm-svn: 51823

llvm-svn: 51822

llvm-svn: 51821