llvm-svn: 143095

It is not safe to sink an alloca into a stacksave/stackrestore pair, so don't do that. <rdar://problem/10352360>

llvm-svn: 143093

llvm-svn: 143086

llvm-svn: 143080

up.  Thus, improving the support for compares is goodness because it increases
the number of terminator instructions we can handle.  This creates many more 
opportunities for target specific fast-isel.

llvm-svn: 143079

place.  No functional change intended.

llvm-svn: 143078

llvm-svn: 143076

change.

llvm-svn: 143074

SelectBranch.  No functional change intended.

llvm-svn: 143072

llvm-svn: 143071

We were parsing label references to the i12 encoding, which isn't right.
They need to go to the pci variant instead.

More of rdar://10348687

llvm-svn: 143068

Patch by Sanjoy Das.

llvm-svn: 143064

Partial fix for rdar://10348687.

llvm-svn: 143063

MORESTACK_RET_RESTORE_R10; which are lowered to a RET and a RET
followed by a MOV respectively.  Having a fake instruction prevents
the verifier from seeing a MachineBasicBlock end with a
non-terminator (MOV).  It also prevents the rather eccentric case of a
MachineBasicBlock ending with RET but having successors nevertheless.

Patch by Sanjoy Das.

llvm-svn: 143062

llvm-svn: 143055

in 403.gcc and was spotted by my super-optimizer.

llvm-svn: 143054

llvm-svn: 143051

composed of one byte characters.

llvm-svn: 143044

The order of the two symbol listings in a Macho x86_64 subtractor relocation is reversed from what seems intuitive to me.

llvm-svn: 143035

llvm-svn: 143034

Include the full 64 bits of relocation data in the type info for MachO relocations, so that we can recognize scattered relocations.

llvm-svn: 143033

llvm-svn: 143032

llvm-svn: 143031

true: (x *nsw x) sgt 0, where x = (y | 1).  This occurs in 464.h264ref.

llvm-svn: 143028

trying to legalize the operand types when only the result type
is required to be legalized - the type legalization machinery
will get round to the operands later if they need legalizing.
There can be a point to legalizing operands in parallel with
the result: when this saves compile time or results in better
code.  There was only one case in which this was true: when
the operand is also split, so keep the logic for that bit.
As a result of this change, additional operand legalization
methods may need to be introduced to handle nodes where the
result and operand types can differ, like SIGN_EXTEND, but
the testsuite doesn't contain any tests where this is the case.
In any case, it seems better to require such methods (and die
with an assert if they doesn't exist) than to quietly produce
wrong code if we forgot to special case the node in
SplitVecRes_UnaryOp.

llvm-svn: 143026

Revert r142530 at least temporarily while a discussion is had on llvm-commits regarding exactly how much optsize should optimize for size over performance.

llvm-svn: 143023

Use a worklist to prevent the iterator from becoming invalidated because of the 'removeSuccessor' call. Noticed in a Release+Asserts+Check buildbot.

llvm-svn: 143018

llvm-svn: 143011

This code makes different decisions when compiled into x87 instructions
because of different rounding behavior.  That caused phase 2/3
miscompares on 32-bit Linux when the phase 1 compiler was built with gcc
(using x87), and the phase 2 compiler was built with clang (using SSE).

This fixes PR11200.

llvm-svn: 143006

Disable LICM speculation in high register pressure situation again now that Devang has fixed other issues.

llvm-svn: 143003

on Darwin platforms where -Os means optimize for size without hurting
performance.

llvm-svn: 143002

An MBB which branches to an EH landing pad shouldn't be considered for tail merging.

In SjLj EH, the jump to the landing pad is not done explicitly through a branch
statement. The EH landing pad is added as a successor to the throwing
BB. Because of that however, the branch folding pass could mistakenly think that
it could merge the throwing BB with another BB. This isn't safe to do.
<rdar://problem/10334833>

llvm-svn: 143001

fix up later. For this special case, allow such a mask to be considered valid.
<rdar://problem/8622574>

llvm-svn: 142992

llvm-svn: 142983

llvm-svn: 142981

llvm-svn: 142970

Add support for the notion of "hidden" relocations.  On MachO, these are relocation entries that are used as additional information for other, real relocations, rather than being relocations themselves.
I'm not familiar enough with ELF or COFF to know if they should have any relocations marked hidden.

llvm-svn: 142961

llvm-svn: 142959

PR11217.

llvm-svn: 142956

llvm-svn: 142938