The symptom is seg-fault, and the root cause is that a SCEV contains a SCEVUnknown
which has null-pointer to a llvm::Value.

 This is how the problem take place:
 ===================================
  1). In the pristine input IR, there are two relevant instrutions Op1 and Op2, 
     Op1's corresponding SCEV (denoted as SCEV(op1)) is a SCEVUnknown, and
     SCEV(Op2) contains SCEV(Op1).  None of these instructions are dead.

     Op1 : V1 = ...
     ...
     Op2 : V2 = ... // directly or indirectly (data-flow) depends on Op1
    
  2) Optimizer (LSR in my case) generates an instruction holding the equivalent
     value of Op1, making Op1 dead. 
     Op1': V1' = ...
     Op1: V1 = ... ; now dead)
     Op2 : V2 = ... //Now deps on Op1', but the SCEV(Op2) still contains SCEV(Op1)

  3) Op1 is deleted, and call-back function is called to reset 
     SCEV(Op1) to indicate it is invalid. However, SCEV(Op2) is not 
     invalidated as well.

  4) Following pass get the cached, invalid SCEV(Op2), and try to manipulate it,
     and cause segfault. 

 The fix:
 ========
 It seems there is no clean yet inexpensive fix. I write to dev-list
soliciting good solution, unforunately no ack. So, I decide to fix this 
problem in a brute-force way:

  When ScalarEvolution::getSCEV is called, check if the cached SCEV 
contains a invalid SCEVUnknow, if yes, remove the cached SCEV, and
re-evaluate the SCEV from scratch.

  I compile buch of big *.c and *.cpp, fortunately, I don't see any increase
in compile time.

 Misc:
=====
 The reduced test-case has 2357 lines of code+other-stuff, too big to commit.

 rdar://14283433

llvm-svn: 185843

Since the pool indexes are necessarily sequential and contiguous, just
insert things in the right place rather than having to sort the sequence
after the fact.

No functionality change.

llvm-svn: 185842

Another bug found by llvm-stress! This fixes crashing with:
  LLVM ERROR: Cannot select: v4f32 = frem ...

llvm-svn: 185840

llvm-svn: 185834

Not intended functionality change.

llvm-svn: 185830

[PowerPC] Support time base instructions

This adds support for the old-style time base instructions;
while new programs are supposed to use mfspr, the mftb instructions
are still supported and in use by existing assembler files.

llvm-svn: 185829

[PowerPC] Support basic compare mnemonics

This adds support for the basic mnemoics (with the L operand) for the
fixed-point compare instructions.  These are defined as aliases for the
already existing CMPW/CMPD patterns, depending on the value of L.

This requires use of InstAlias patterns with immediate literal operands.
To make this work, we need two further changes:

 - define a RegisterPrefix, because otherwise literals 0 and 1 would
   be parsed as literal register names

 - provide a PPCAsmParser::validateTargetOperandClass routine to
   recognize immediate literals (like ARM does)

llvm-svn: 185826

In response to Duncan's review, I believe that the original comment was not as
clear as it could be. Hopefully, this is better.

llvm-svn: 185824

PPCTargetLowering::LowerFP_TO_INT() expects its source operand to be
either an f32 or f64, but this is not checked.  A long double
(ppcf128) operand will normally be custom-lowered to a conversion to
f64 in this context.  However, this isn't the case for an UNDEF node.

This patch recognizes a ppcf128 as a legal source operand for
FP_TO_INT only if it's an undef, in which case it creates an undef of
the target type.

At some point we might want to do a wholesale custom lowering of
ISD::UNDEF when the type is ppcf128, but it's not really clear that's
a great idea, and probably more work than it's worth for a situation
that only arises in the case of a programming error.  At this point I
think simple is best.

The test case comes from PR16556, and is a crash-test only.

llvm-svn: 185821

Back in r179493 we determined that two transforms collided with each
other.  The fix back then was to reorder the transforms so that the
preferred transform would give it a try and then we would try the
secondary transform.  However, it was noted that the best approach would
canonicalize one transform into the other, removing the collision and
allowing us to optimize IR given to us in that form.

llvm-svn: 185808

Reapply this as I reverted the wrong commit.

llvm-svn: 185807

This reverts commit 2b52880592a525cfe04d8f9008a35da8c2ea94c3.

Needs review.

llvm-svn: 185806

I was originally going to use MVC for memmove too, but that's less of
a clear win.  Remove some accidental left-overs in the previous commit.

llvm-svn: 185804

Use MVC for memcpy in cases where a single MVC is enough.  Using MVC is
a win for longer copies too, but I'll leave that for later.

llvm-svn: 185802

This fixes a bug (found by llvm-stress) in
DAGTypeLegalizer::PromoteIntRes_BUILD_VECTOR where it assumed that the result
type would always be larger than the original operands. This is not always
true, however, with boolean vectors. For example, promoting a node of type v8i1
(where the operands will be of type i32, the type to which i1 is promoted) will
yield a node with a result vector element type of i16 (and operands of type
i32). As a result, we cannot blindly assume that we can ANY_EXTEND the operands
to the result type.

llvm-svn: 185794

llvm-svn: 185793

llvm-svn: 185791

llvm-svn: 185790

llvm-svn: 185788

This fixes an oversight that Intrinsic::nearbyint was not being mapped to
ISD::FNEARBYINT (thus fixing the over-optimistic cost we were assigning to
nearbyint calls for some targets).

llvm-svn: 185783

This reverts commit 01f8d579f7672872324208ac5bc4ac311e81b22e.

llvm-svn: 185781

llvm-svn: 185780

llvm-svn: 185778

llvm-svn: 185777

pointer arguments.

llvm-svn: 185776

This is a complete re-write if the bottom-up vectorization class.
Before this commit we scanned the instruction tree 3 times. First in search of merge points for the trees. Second, for estimating the cost. And finally for vectorization.
There was a lot of code duplication and adding the DCE exposed bugs. The new design is simpler and DCE was a part of the design.
In this implementation we build the tree once. After that we estimate the cost by scanning the different entries in the constructed tree (in any order). The vectorization phase also works on the built tree.

llvm-svn: 185774

Upon further reflection, the alias analysis part of r185764 is not a safe
change.

llvm-svn: 185770

[objc-arc] Teach the ARC optimizer that objc_sync_enter/objc_sync_exit do not modify the ref count of an objc object and additionally are inert for modref purposes.

llvm-svn: 185769

llvm-svn: 185768

llvm-svn: 185767

[objc-arc] When we initialize ARCRuntimeEntryPoints, make sure we reset all references to entrypoint declarations as well.

llvm-svn: 185764

llvm-svn: 185763

Obviously the personality function should be emitted as language handler
instead of the hard coded _GCC_specific_handler. The language specific
data must be placed after the unwind information therefore it must not
be emitted into a separate section.

Reviewed by Charles Davis and Nico Rieck.

llvm-svn: 185761

For alignment purposes, the instruction array will always have an even
number of entries, with the final entry potentially unused (in which
case the array will be one longer than indicated by the count of unwind
codes field).

Reviewed by Charles Davis and Nico Rieck.

llvm-svn: 185760

 data structures.

The Win64 EH data structures must be of type IMAGE_REL_AMD64_ADDR32NB
instead of IMAGE_REL_AMD64_ADDR32. This is easiely achieved by adding
the VK_COFF_IMGREL32 modifier to the symbol reference.
Change also references to start and end of the SEH range of a function
as offsets to start of the function.

Reviewed by Charles Davis and Nico Rieck.

llvm-svn: 185759

The code offset for unwind code SET_FPREG is wrong because it is set
to constant 0. The fix is to do the same as for the other unwind
codes: emit a label and later the absolute difference between the
label and the begin of the prologue.
Also enables the failing test case MC/COFF/seh.s

Reviewed by Charles Davis and Nico Rieck.

llvm-svn: 185758

llvm-svn: 185757

ReduceLoadWidth unconditionally drops extensions from loads. Limit it to the
case when all of the bits the extension would otherwise produce are dropped by
the shrink. It would be possible to shrink the load in more cases by merging
the extensions, but this isn't trivial and a very rare case. I left a TODO for
that case.

Fixes PR16551.

llvm-svn: 185755

This prevents the emission of DAG-generated vreg definitions after a
tail call be dropping them entirely (on the grounds that nothing could
use them anyway, and they interfere with O0 CodeGen).

llvm-svn: 185754

llvm-svn: 185753