llvm-svn: 36449

clobbered by a call.

llvm-svn: 36448

llvm-svn: 36447

llvm-svn: 36446

llvm-svn: 36445

llvm-svn: 36444

llvm-svn: 36443

when promoted to 64-bits

llvm-svn: 36442

llvm-svn: 36441

llvm-svn: 36440

llvm-svn: 36439

llvm-svn: 36438

llvm-svn: 36437

will follow.

llvm-svn: 36435

- A register def / use now implicitly affects sub-register liveness but does
not affect liveness information of super-registers.
- Def of a larger register (if followed by a use later) is treated as
read/mod/write of a smaller register.

llvm-svn: 36434

llvm-svn: 36433

llvm-svn: 36432

llvm-svn: 36431

llvm-svn: 36430

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: 36428

llvm-svn: 36427

llvm-svn: 36426

llvm-svn: 36425

llvm-svn: 36424

llvm-svn: 36423

llvm-svn: 36422

this approach is no longer appropriate.

llvm-svn: 36421

llvm-svn: 36420

llvm-svn: 36419

llvm-svn: 36418

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

llvm-svn: 36417

llvm-svn: 36416

llvm-svn: 36415

llvm-svn: 36414

This fixes CodeGen/X86/2007-04-24-VectorCrash.ll

llvm-svn: 36413

llvm-svn: 36412

llvm-svn: 36411

llvm-svn: 36410

llvm-svn: 36409