to get important constant branch probabilities and use them for finding
the best branch out of a set of possibilities.

llvm-svn: 142762

llvm-svn: 142761

50% is much more readable than 5.000000e-01.

llvm-svn: 142752

llvm-svn: 142751

discussions with Andy. Fundamentally, the previous algorithm is both
counter productive on several fronts and prioritizing things which
aren't necessarily the most important: static branch prediction.

The new algorithm uses the existing loop CFG structure information to
walk through the CFG itself to layout blocks. It coalesces adjacent
blocks within the loop where the CFG allows based on the most likely
path taken. Finally, it topologically orders the block chains that have
been formed. This allows it to choose a (mostly) topologically valid
ordering which still priorizes fallthrough within the structural
constraints.

As a final twist in the algorithm, it does violate the CFG when it
discovers a "hot" edge, that is an edge that is more than 4x hotter than
the competing edges in the CFG. These are forcibly merged into
a fallthrough chain.

Future transformations that need te be added are rotation of loop exit
conditions to be fallthrough, and better isolation of cold block chains.
I'm also planning on adding statistics to model how well the algorithm
does at laying out blocks based on the probabilities it receives.

The old tests mostly still pass, and I have some new tests to add, but
the nested loops are still behaving very strangely. This almost seems
like working-as-intended as it rotated the exit branch to be
fallthrough, but I'm not convinced this is actually the best layout. It
is well supported by the probabilities for loops we currently get, but
those are pretty broken for nested loops, so this may change later.

llvm-svn: 142743

llvm-svn: 142741

element types, even though the element extraction code does. It is surprising
that this bug has been here for so long. Fixes <rdar://problem/10318778>.

llvm-svn: 142740

llvm-svn: 142738

llvm-svn: 142737

llvm-svn: 142736

elimination on them too.

llvm-svn: 142735

able to constant fold load instructions where the argument is a constant.
Second, we should be able to watch multiple PHI nodes through the loop; this
patch only supports PHIs in loop headers, more can be done here.

With this patch, we now constant evaluate:
  static const int arr[] = {1, 2, 3, 4, 5};
  int test() {
    int sum = 0;
    for (int i = 0; i < 5; ++i) sum += arr[i];
    return sum;
  }

llvm-svn: 142731

llvm-svn: 142729

llvm-svn: 142728

llvm-svn: 142727

llvm-svn: 142726

SHL inserts zeros from the right, thus even when the original
sign_extend_inreg value was of 1-bit, we need to sra.

llvm-svn: 142724

that the set of callee-saved registers is correct for the specific platform.
<rdar://problem/10313708> & ctor_dtor_count & ctor_dtor_count-2

llvm-svn: 142706

llvm-svn: 142704

llvm-svn: 142691

The assumption in the back-end is that PHIs are not allowed at the start of the
landing pad block for SjLj exceptions.
<rdar://problem/10313708>

llvm-svn: 142689

llvm-svn: 142687

Revert r141657 for now. This has broken css and changed links on llvm.org. I'd like to understand exactly why the links have changed and if a newer doxygen is required. This may be reapplied once we upgrade on llvm.org and it is fully tested.

llvm-svn: 142686

llvm-svn: 142684

llvm-svn: 142683

llvm-svn: 142682

llvm-svn: 142681

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

llvm-svn: 142677

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

llvm-svn: 142667

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