running tail duplication when doing branch folding for if-conversion, and
we also want to be able to run tail duplication earlier to fix some
reg alloc problems.  Move the CanFallThrough function from BranchFolding
to MachineBasicBlock so that it can be shared by TailDuplication.

llvm-svn: 89904

llvm-svn: 89899

llvm-svn: 89896

Rollback changes r89516: Added two SubtargetFeatures::AddFeatures methods, which accept a comma-separated string or already parsed command line parameters as input, and some code re-factoring to use these new methods.

llvm-svn: 89893

ProcessImplicitDefs should watch out for invalidated iterator and extra implicit operands on copies.

llvm-svn: 89880

With the testcase for pr3120, the "threaded interpreter" runtime decreases
from 1788 to 1413 with this change.

llvm-svn: 89877

llvm-svn: 89873

llvm-svn: 89866

it is definitely profitable to tail duplicate indirect branches for x86.
This is likely to be true to various degrees for all modern x86 processors.

llvm-svn: 89865

llvm-svn: 89863

llvm-svn: 89862

llvm-svn: 89850

API change Path::isSpecialFile to Path::isRegularFile, improve semantics in regards to comments from 89765 post review.

llvm-svn: 89848

llvm-svn: 89846

llvm-svn: 89844

llvm-svn: 89841

llvm-svn: 89840

llvm-svn: 89839

llvm-svn: 89833

using two swc/lwc instead of sdc/ldc.

llvm-svn: 89826

llvm-svn: 89824

unnecessary save/restore.

llvm-svn: 89823

llvm-svn: 89821

llvm-svn: 89819

Make tail duplication of indirect branches much more aggressive (for targets
that indicate that it is profitable), based on further experience with
this transformation.  I compiled 3 large applications with and without
this more aggressive tail duplication and measured minimal changes in code
size.  ("size" on Darwin seems to round the text size up to the nearest
page boundary, so I can only say that any code size increase was less than
one 4k page.) Radar 7421267.

llvm-svn: 89814

This violates the ABI (that area is "reserved"), and
while it is safe if all code is generated with current
compilers, there is some very old code around that uses
that slot for something else, and breaks if it is stored
into.  Adjust testcases looking for current behavior.
I've verified that the stack frame size is right in all
testcases, whether it changed or not.  7311323.

llvm-svn: 89811

llvm-svn: 89803

llvm-svn: 89793

llvm-svn: 89790

llvm-svn: 89787

llvm-svn: 89786

llvm-svn: 89770

llvm-svn: 89765

llvm-svn: 89758

llvm-svn: 89748

make far calls work.

llvm-svn: 89733

llvm-svn: 89729

llvm-svn: 89725

No functional change.

llvm-svn: 89724

llvm-svn: 89723