llvm-svn: 142681

Example (start the lldb inferior, break at the Driver::MainLoop() function, and
issue 'frame variable'):

 $ ./dotest.py -v +b -x '-F Driver::MainLoop()' -n -p TestFrameVariableResponse.py
----------------------------------------------------------------------
Collected 1 test

1: test_startup_delay (TestFrameVariableResponse.FrameVariableResponseBench)
   Test response time for the 'frame variable' command. ... 
lldb frame variable benchmark: Avg: 1.636897 (Laps: 20, Total Elapsed Time: 32.737944)
ok

----------------------------------------------------------------------
Ran 1 test in 65.105s

OK

llvm-svn: 142678

This is from the same paper from Ball and Larus as the rest of the currently implemented heuristics.

llvm-svn: 142677

llvm-svn: 142676

llvm-svn: 142675

llvm-svn: 142673

llvm-svn: 142672

Extend instcombine's shufflevector simplification to handle more cases where the input and output vectors have different sizes.  Patch by Xiaoyi Guo.

llvm-svn: 142671

Next step in the ongoing saga of NEON load/store assmebly parsing. Handle
VLD1 instructions that take a two-register register list.

Adjust the instruction definitions to only have the single encoded register
as an operand. The super-register from the pseudo is kept as an implicit def,
so passes which come after pseudo-expansion still know that the instruction
defines the other subregs.

llvm-svn: 142670

Don't automatically set the "fc" bits on MSR instructions if the user didn't ask for them.  This is a divergence from gas' behavior, but it is correct per the documentation and allows us to forge ahead with roundtrip testing.

llvm-svn: 142669

which happen before the listingings of test cases.

llvm-svn: 142668

llvm-svn: 142667

llvm-svn: 142666

llvm-svn: 142665

ivars in class extensions. // rdar://10309454

llvm-svn: 142664

llvm-svn: 142663

Expand the coverage of the libObject C bindings to include more SectionRef accessors as well as Symbol iterators.

llvm-svn: 142661

ZExtPromotedInteger and SExtPromotedInteger based on the operation we legalize.

SetCC return type needs to be legalized via PromoteTargetBoolean.

llvm-svn: 142660

llvm-svn: 142658

llvm-svn: 142657

all x86 systems. Sorry for the breakage.

llvm-svn: 142656

addDecl() and makeDeclVisibleInContextInternal()
functions, and made the latter private since it
does not and should not have external clients.

llvm-svn: 142655

llvm-svn: 142654

llvm-svn: 142653

be sure to consider all of the possible lookup results. We were
assert()'ing (but behaving correctly) for unresolved values. Fixes
PR11134 / <rdar://problem/10290422>.

llvm-svn: 142652

llvm-svn: 142649

2. Fix a typo in CONCAT_VECTORS which exposed the bug in #1.

llvm-svn: 142648

llvm-svn: 142647

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

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