llvm-svn: 36873

llvm-svn: 36857

llvm-svn: 36809

llvm-svn: 36807

If we have a LCSSA, only modify the input value if the inval was defined
by an instruction in the loop.  If defined by something before the loop,
it is still valid.

llvm-svn: 36784

llvm-svn: 36782

llvm-svn: 36775

slightly nicer than using CallInst with an extra check; thanks Chris.

llvm-svn: 36743

address operand in a prefetch intrinsic.

llvm-svn: 36713

llvm-svn: 36662

Due to darwin gcc bug, one version of darwin linker coalesces
static const int, which defauts PassID based pass identification.

llvm-svn: 36652

llvm-svn: 36632

llvm-svn: 36527

previous clients.  This fixes MallocBench/gs

llvm-svn: 36525

llvm-svn: 36523

llvm-svn: 36521

for unrelated casts.

llvm-svn: 36511

llvm-svn: 36475

llvm-svn: 36444

llvm-svn: 36441

copies from a constant global, then we can change the reads to read from the
global instead of from the alloca.  This eliminates the alloca and the memcpy,
and promotes secondary optimizations (because the loads are now loads from
a constant global).

This is important for a common C idiom:

void foo() {
   int A[] = {1,2,3,4,5,6,7,8,9...};
   ... only reads of A ...
}

For some reason, people forget to mark the array static or const.

This triggers on these multisource benchmarks:
JM/ldecode: block_pos, [3 x [4 x [4 x i32]]]
FreeBench/mason: m, [18 x i32], inlined 4 times
MiBench/office-stringsearch: search_strings, [1332 x i8*]
MiBench/office-stringsearch: find_strings, [1333 x i8*]
Prolangs-C++/city: dirs, [9 x i8*], inlined 4 places

and these spec benchmarks:
177.mesa: message, [8 x [32 x i8]]
186.crafty: bias_rl45, [64 x i32]
186.crafty: diag_sq, [64 x i32]
186.crafty: empty, [9 x i8]
186.crafty: xlate, [15 x i8]
186.crafty: status, [13 x i8]
186.crafty: bdinfo, [25 x i8]
445.gobmk: routines, [16 x i8*]
458.sjeng: piece_rep, [14 x i8*]
458.sjeng: t, [13 x i32], inlined 4 places.
464.h264ref: block8x8_idx, [3 x [4 x [4 x i32]]]
464.h264ref: block_pos, [3 x [4 x [4 x i32]]]
464.h264ref: j_off_tab, [12 x i32]

This implements Transforms/ScalarRepl/memcpy-from-global.ll

llvm-svn: 36429

llvm-svn: 36426

this approach is no longer appropriate.

llvm-svn: 36421

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070423/048376.html

llvm-svn: 36417

my approach to this, so hopefully I'll find a way to do this without making this slower.

llvm-svn: 36392

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070423/048333.html

llvm-svn: 36380

llvm-svn: 36300

llvm-svn: 36299

llvm-svn: 36271

llvm-svn: 36261

llvm-svn: 36260

llvm-svn: 36255

llvm-svn: 36254

llvm-svn: 36252

llvm-svn: 36249

gets called.

llvm-svn: 36208

Fix
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070416/047888.html

llvm-svn: 36182

target for tabs checking.

llvm-svn: 36146

Remove ImmediateDominator analysis.  The same information can be obtained from DomTree.  A lot of code for
constructing ImmediateDominator is now folded into DomTree construction.

This is part of the ongoing work for PR217.

llvm-svn: 36063

This sinks the two stores in this example into a single store in cond_next.  In this
case, it allows elimination of the load as well:

        store double 0.000000e+00, double* @s.3060
        %tmp3 = fcmp ogt double %tmp1, 5.000000e-01             ; <i1> [#uses=1]
        br i1 %tmp3, label %cond_true, label %cond_next
cond_true:              ; preds = %entry
        store double 1.000000e+00, double* @s.3060
        br label %cond_next
cond_next:              ; preds = %entry, %cond_true
        %tmp6 = load double* @s.3060            ; <double> [#uses=1]

This implements Transforms/InstCombine/store-merge.ll:test2

llvm-svn: 36040