Patch by Ruben Van Boxem!

llvm-svn: 142646

it's a bit more plausible to use this instead of CodePlacementOpt. The
code for this was shamelessly stolen from CodePlacementOpt, and then
trimmed down a bit. There doesn't seem to be much utility in returning
true/false from this pass as we may or may not have rewritten all of the
blocks. Also, the statistic of counting how many loops were aligned
doesn't seem terribly important so I removed it. If folks would like it
to be included, I'm happy to add it back.

This was probably the most egregious of the missing features, and now
I'm going to start gathering some performance numbers and looking at
specific loop structures that have different layout between the two.

Test is updated to include both basic loop alignment and nested loop
alignment.

llvm-svn: 142645

canonical example I used when developing it, and is one of the primary
motivating real-world use cases for __builtin_expect (when burried under
a macro).

I'm working on more test cases here, but I'm trying to make sure both
that the pass is doing the right thing with the test cases and that they
aren't too brittle to changes elsewhere in the code generation pipeline.

Feedback and/or suggestions on how to test this are very welcome.
Especially feedback on whether testing the block comments is a good
strategy; I couldn't find any good examples to steal from but all the
other ideas I had were a lot uglier or more fragile.

llvm-svn: 142644

Modify the script to output the regressions and passes into categories. My Python-fu could use some improving...

llvm-svn: 142643

Remove intrinsics for X86 BLSI, BLSMSK, and BLSR intrinsics and replace with custom isel lowering code.

llvm-svn: 142642

block frequency analyses. This differs substantially from the existing
block-placement pass in LLVM:

1) It operates on the Machine-IR in the CodeGen layer. This exposes much
   more (and more precise) information and opportunities. Also, the
   results are more stable due to fewer transforms ocurring after the
   pass runs.
2) It uses the generalized probability and frequency analyses. These can
   model static heuristics, code annotation derived heuristics as well
   as eventual profile loading. By basing the optimization on the
   analysis interface it can work from any (or a combination) of these
   inputs.
3) It uses a more aggressive algorithm, both building chains from tho
   bottom up to maximize benefit, and using an SCC-based walk to layout
   chains of blocks in a profitable ordering without O(N^2) iterations
   which the old pass involves.

The pass is currently gated behind a flag, and not enabled by default
because it still needs to grow some important features. Most notably, it
needs to support loop aligning and careful layout of loop structures
much as done by hand currently in CodePlacementOpt. Once it supports
these, and has sufficient testing and quality tuning, it should replace
both of these passes.

Thanks to Nick Lewycky and Richard Smith for help authoring & debugging
this, and to Jakob, Andy, Eric, Jim, and probably a few others I'm
forgetting for reviewing and answering all my questions. Writing
a backend pass is *sooo* much better now than it used to be. =D

llvm-svn: 142641

llvm-svn: 142640

Clang.

llvm-svn: 142631

llvm-svn: 142630

llvm-svn: 142626

llvm-svn: 142624

Remove unused include of sys/uio.h in MemoryBuffer.cpp. It was not correctly protected by ifdef either.

llvm-svn: 142623

llvm-svn: 142622

top-down scheduling and top-down scheduling is going away.

llvm-svn: 142621

because they don't support physical register dependencies.

llvm-svn: 142620

Separate out ARM MSR instructions into M-class versions and AR-class versions.  This fixes some roundtripping failures.

llvm-svn: 142618

llvm-svn: 142615

llvm-svn: 142608

the last compiler built for the previous flavour is used for the next,
for example the Debug clang compiler was being used for the initial build
of the Release LLVM.  Flavors should be independent of each other.  This
especially matters if the compiler built for the previous flavour doesn't
actually work!

llvm-svn: 142607

AsmParser. This patch adds validation for target data layout strings upon
construction of TargetData objects. An attempt to construct a TargetData object
from a malformed string will trigger an assertion.

llvm-svn: 142605

causing one of the unit tests to infinitely loop, which resulted in the 
buildbots stalling.

llvm-svn: 142604

llvm-svn: 142593

llvm-svn: 142592

llvm-svn: 142591

llvm-svn: 142583

llvm-svn: 142582

llvm-svn: 142581

llvm-svn: 142579

In fact this commit is not intended to change anything unless you
use one of the new command line flags.

llvm-svn: 142577

compiler warnings.

llvm-svn: 142574

llvm-svn: 142573

Refactor code from inlining and globalopt that checks whether a function definition is unused, and enhance it so it can tell that functions which are only used by a blockaddress are in fact dead.  This probably doesn't happen much on most code, but the Linux kernel's _THIS_IP_ can trigger this issue with blockaddress.  (GlobalDCE can also handle the given tescase, but we only run that at -O3.)  Found while looking at PR11180.

llvm-svn: 142572

llvm-svn: 142570

llvm-svn: 142569

llvm-svn: 142567

llvm-svn: 142559

correctly in GetStringLength, fixing PR11181!

llvm-svn: 142558

llvm-svn: 142557

Patch by Pranav Bhandarkar!

llvm-svn: 142556

llvm-svn: 142550