Add prototype code for recomputing a live interval's ranges and valnos through recursive phi construction.

llvm-svn: 61458

parameters are pointers.

llvm-svn: 61451

  DAGcombine's ability to find reasons to remove truncates when they were not
  needed. Consequently, the CellSPU backend would produce correct, but _really
  slow and horrible_, code.

  Replaced with instruction sequences that do the equivalent truncation in
  SPUInstrInfo.td.

- Re-examine how unaligned loads and stores work. Generated unaligned
  load code has been tested on the CellSPU hardware; see the i32operations.c
  and i64operations.c in CodeGen/CellSPU/useful-harnesses.  (While they may be
  toy test code, it does prove that some real world code does compile
  correctly.)

- Fix truncating stores in bug 3193 (note: unpack_df.ll will still make llc
  fault because i64 ult is not yet implemented.)

- Added i64 eq and neq for setcc and select/setcc; started new instruction
  information file for them in SPU64InstrInfo.td. Additional i64 operations
  should be added to this file and not to SPUInstrInfo.td.

llvm-svn: 61447

llvm-svn: 61426

llvm-svn: 61425

llvm-svn: 61424

llvm-svn: 61423

llvm-svn: 61420

about other platforms.

llvm-svn: 61415

a symbolic constant. This is unlikely to be intentional, but it
shouldn't crash the compiler.

llvm-svn: 61408

llvm-svn: 61407

llvm-svn: 61405

llvm-svn: 61404

llvm-svn: 61403

other SPEC breakage.  I'll be reverting all recent
changes shortly, this checking is mostly so this
change doesn't get lost.

llvm-svn: 61402

llvm-svn: 61401

llvm-svn: 61400

llvm-svn: 61398

llvm-svn: 61397

llvm-svn: 61396

llvm-svn: 61395

llvm-svn: 61392

Silence unused variable warning.

llvm-svn: 61391

llvm-svn: 61390

This removes all the _8, _16, _32, and _64 opcodes and replaces each
group with an unsuffixed opcode. The MemoryVT field of the AtomicSDNode
is now used to carry the size information. In tablegen, the size-specific
opcodes are replaced by size-independent opcodes that utilize the
ability to compose them with predicates.

This shrinks the per-opcode tables and makes the code that handles
atomics much more concise.

llvm-svn: 61389

llvm-svn: 61385

llvm-svn: 61378

code in ScheduleDAGSDNodes' BuildSchedGraph into separate functions.

llvm-svn: 61376

several places. isTerminator() returns true for a superset
of cases, and includes things like FP_REG_KILL, which are
nither return or branch but aren't safe to move/remat/etc.

llvm-svn: 61373

llvm-svn: 61372

llvm-svn: 61371

llvm-svn: 61369

llvm-svn: 61368

Fixed lowering of v8i16 shuffles for v8i16 when we fall back to extract/insert.

llvm-svn: 61365

my last patch to this file.

The issue there was that all uses of an IV inside a loop
are actually references to Base[IV*2], and there was one
use outside that was the same but LSR didn't see the base
or the scaling because it didn't recurse into uses outside
the loop; thus, it used base+IV*scale mode inside the loop
instead of pulling base out of the loop.  This was extra bad
because register pressure later forced both base and IV into
memory.  Doing that recursion, at least enough
to figure out addressing modes, is a good idea in general;
the change in AddUsersIfInteresting does this.  However,
there were side effects....

It is also possible for recursing outside the loop to
introduce another IV where there was only 1 before (if
the refs inside are not scaled and the ref outside is).
I don't think this is a common case, but it's in the testsuite.
It is right to be very aggressive about getting rid of
such introduced IVs (CheckForIVReuse and the handling of
nonzero RewriteFactor in StrengthReduceStridedIVUsers).
In the testcase in question the new IV produced this way
has both a nonconstant stride and a nonzero base, neither
of which was handled before.  And when inserting 
new code that feeds into a PHI, it's right to put such 
code at the original location rather than in the PHI's 
immediate predecessor(s) when the original location is outside 
the loop (a case that couldn't happen before)
(RewriteInstructionToUseNewBase); better to avoid making
multiple copies of it in this case.

Also, the mechanism for keeping SCEV's corresponding to GEP's
no longer works, as the GEP might change after its SCEV
is remembered, invalidating the SCEV, and we might get a bad
SCEV value when looking up the GEP again for a later loop.  
This also couldn't happen before, as we weren't recursing
into GEP's outside the loop.

I owe some testcases for this, want to get it in for nightly runs.

llvm-svn: 61362

llvm-svn: 61361

llvm-svn: 61358

llvm-svn: 61356

llvm-svn: 61354

llvm-svn: 61353