llvm-svn: 143073

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

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

llvm-svn: 143045

composed of one byte characters.

llvm-svn: 143044

llvm-svn: 143042

llvm-svn: 143041

llvm-svn: 143040

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

llvm-svn: 143024

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

llvm-svn: 143022

llvm-svn: 143020

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

llvm-svn: 143011

version of the install program, which does not have the --strip-program
switch.

llvm-svn: 143009

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

Add a note about the removal of the atomic intrinsics to the "Major Changes" section of the release notes.

llvm-svn: 142998

to use for stripping final executables.

Patch by Simon Atanasyan!

llvm-svn: 142997

Patch by Dimitry Andric!

llvm-svn: 142995

llvm-svn: 142994

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

llvm-svn: 142992