llvm-svn: 100274

llvm-svn: 100273

llvm-svn: 100272

are in the same block.  Insert the new increment in the
correct location.

Also, more cleanups.

llvm-svn: 100271

this cleans up a bunch of code and also fixes several crashes and
miscompiles.  More to come unfortunately, this optimization
is quite broken.

llvm-svn: 100270

llvm-svn: 100262

llvm-svn: 100199

Added support for address spaces and added a isVolatile field to memcpy, memmove, and memset,
e.g., llvm.memcpy.i32(i8*, i8*, i32, i32) -> llvm.memcpy.p0i8.p0i8.i32(i8*, i8*, i32, i32, i1)

llvm-svn: 100191

it can't currently observe such changes automatically.

llvm-svn: 100186

is necessary. Inherits from new templated baseclass CallSiteBase<>
which is highly customizable. Base CallSite on it too, in a configuration
that allows full mutation.
Adapt some call sites in analyses to employ ImmutableCallSite.

llvm-svn: 100100

generate wrong code pretty much anywhere AFAICT.
A case that hits the bug reproducibly is impossible,
but the situation was like this:
Addr = ...
Store -> Addr
Addr2 = GEP , 0, 0
Store -> Addr2
Handling the first store, the code changed replaced Addr
with a sunkaddr and deleted Addr, but not its table
entry.  Code in OptimizedBlock replaced Addr2 with a
bitcast; if that happened to reuse the memory of Addr,
the old table entry was erroneously found when handling
the second store.

llvm-svn: 100044

llvm-svn: 99948

e.g., llvm.memcpy.i32(i8*, i8*, i32, i32) -> llvm.memcpy.p0i8.p0i8.i32(i8*, i8*, i32, i32, i1)
A update of langref will occur in a subsequent checkin.

llvm-svn: 99928

pointer.  There was also a SmallPtrSet whose settiness wasn't being used, so I
changed it to a SmallVector.

llvm-svn: 99713

llvm-svn: 99711

MemoizedResultChart.

llvm-svn: 99710

llvm-svn: 99580

llvm-svn: 99564

llvm-svn: 99488

llvm-svn: 99418

I have audited all getOperandNo calls now, fixing
hidden assumptions. CallSite related uglyness will
be eliminated successively.

Note this patch has a long and griveous history,
for all the back-and-forths have a look at
CallSite.h's log.

llvm-svn: 99399

llvm-svn: 99395

llvm-svn: 99324

Teach simplify libcall to transform __strcpy_chk to __memcpy_chk to enable optimizations down stream.

llvm-svn: 99282

llvm-svn: 99171

we can reapply the InvokeInst operand reordering patch. (see r98957).

llvm-svn: 99170

so that the SCEVExpander doesn't retain a dangling pointer as its
insert position. The dangling pointer in this case wasn't ever used
to insert new instructions, but it was causing trouble with
SCEVExpander's code for automatically advancing its insert position
past debug intrinsics.

This fixes use-after-free errors that valgrind noticed in
test/Transforms/IndVarSimplify/2007-06-06-DeleteDanglesPtr.ll and
test/Transforms/IndVarSimplify/exit_value_tests.ll.

llvm-svn: 99036

back out r98957, it broke http://smooshlab.apple.com:8010/builders/clang-x86_64-darwin10-fnt/builds/703 in the nightly test suite

llvm-svn: 98958

This time I did a self-hosted bootstrap on Linux x86-64,
with no problems. Let's see how darwin 64-bit self-hosting
goes. At the first sign of failure I'll back this out.

Maybe the valgrind bots give me a hint of what may be wrong
(it at all).

llvm-svn: 98957

str[r]chr returns its pointer argument so we cannot mark it as nocapture. Thanks to Duncan for spotting my mistake.

llvm-svn: 98671

llvm-svn: 98663

llvm-svn: 98584

In "empty" bb, the return instruction may not be first instruction, if dbg value intrinsics are present in this bb. Use terminator to find return instructions. 

llvm-svn: 98565

llvm-svn: 98491

to unify the almost identical code in CodeGenPrepare and InstCombineCalls.

llvm-svn: 98338

llvm-svn: 98297

llvm-svn: 98296

stpcpy is so similar to strcpy, it doesn't deserve a complete copy of the __strcpy_chk -> strcpy code.

llvm-svn: 98284

llvm-svn: 98274

that in InstCombineCalls.

More call lowering needed.

llvm-svn: 98228