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

importation fixes, reducing the amount of requests
made to LLDB for unknown types and increasing 
fidelity of the expression parser.

llvm-svn: 142639

of arbitrary pointers, allowing direct dereferences
of literal addresses.  Also disabled special-cased
generation of certain expression results (especially
casts), substituting the IR interpreter.

llvm-svn: 142638

under bash or under cmd.exe.

llvm-svn: 142637

keyword, because both libstdc++ and libc++ use "__except" as an
identifier. Fixes <rdar://problem/10322555>.

llvm-svn: 142636

llvm-svn: 142635

addDeclInternal().  This function suppresses any
calls to FindExternalVisibleDeclsByName() while
a Decl is added to a DeclContext.  This behavior
is required for the ASTImporter, because in the
case of the LLDB client the ASTImporter would be
called recursively to import the visible decls,
which leads to assertions because the recursive
call is seeing partially-formed types.

I also modified the ASTImporter to use
addDeclInternal() in all places where it would
otherwise use addDecl().  This fix should not
affect the rest of Clang, passes Clang's
testsuite, and fixes several serious LLDB bugs.

llvm-svn: 142634

closer to what GCC does, except that GCC also checks that the inodes for $PWD
and '.' match.

llvm-svn: 142633

llvm-svn: 142632

Clang.

llvm-svn: 142631

llvm-svn: 142630

llvm-svn: 142629

o create a fresh target; and
o set the first breakpoint

Example (using lldb to set a breakpoint on lldb's Driver::MainLoop function):

./dotest.py -v +b -x '-F Driver::MainLoop()' -p TestStartupDelays.py

...

1: test_startup_delay (TestStartupDelays.StartupDelaysBench)
   Test start up delays creating a target and setting a breakpoint. ... 
lldb startup delays benchmark:
create fresh target: Avg: 0.106732 (Laps: 15, Total Elapsed Time: 1.600985)
set first breakpoint: Avg: 0.102589 (Laps: 15, Total Elapsed Time: 1.538832)
ok

llvm-svn: 142628

tables (like the .apple_namespaces) and it would cause us to index DWARF that
didn't need to be indexed.

Updated the MappedHash.h (generic Apple accelerator table) and the DWARF
specific one (HashedNameToDIE.h) to be up to date with the latest and
greatest hash table format.

llvm-svn: 142627

llvm-svn: 142626

check that the option arg in '-x opt_arg' does not start with a '-' char.

llvm-svn: 142625

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

but trivially constructible and destructible variables in C++11 mode. Also
incidentally improve the precision of the wording for jump diagnostics in C++98
mode.

llvm-svn: 142619

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

llvm-svn: 142618

the anonymous union as valid: our fixes have Fix-Its.

llvm-svn: 142616

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

Add test case for analyzer crash reported in <rdar://problem/10308201> (which is already fixed in mainline).

llvm-svn: 142606

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

llvm-svn: 142602

llvm-svn: 142601

Parameterize the iteration count used when running benchmarks, instead of hard-coded inside the test case.
Add a '-y count' option to the test driver for this purpose.  An example:

 $  ./dotest.py -v -y 25 +b -p TestDisassembly.py

...

----------------------------------------------------------------------
Collected 2 tests

1: test_run_gdb_then_lldb (TestDisassembly.DisassembleDriverMainLoop)
   Test disassembly on a large function with lldb vs. gdb. ... 
gdb benchmark: Avg: 0.226305 (Laps: 25, Total Elapsed Time: 5.657614)
lldb benchmark: Avg: 0.113864 (Laps: 25, Total Elapsed Time: 2.846606)
lldb_avg/gdb_avg: 0.503146
ok
2: test_run_lldb_then_gdb (TestDisassembly.DisassembleDriverMainLoop)
   Test disassembly on a large function with lldb vs. gdb. ... 
lldb benchmark: Avg: 0.113008 (Laps: 25, Total Elapsed Time: 2.825201)
gdb benchmark: Avg: 0.225240 (Laps: 25, Total Elapsed Time: 5.631001)
lldb_avg/gdb_avg: 0.501723
ok

----------------------------------------------------------------------
Ran 2 tests in 41.346s

OK

llvm-svn: 142598

gcc's behaviour), and a -Wc++98-compat-pedantic warning for C++11.

llvm-svn: 142597