Rename AnalysisContext to AnalysisDeclContext.  Not only is this name more accurate, but it frees up the name AnalysisContext for other uses.

llvm-svn: 142782

loop header when computing the trip count.

With this, we now constant evaluate:
  struct ListNode { const struct ListNode *next; int i; };
  static const struct ListNode node1 = {0, 1};
  static const struct ListNode node2 = {&node1, 2};
  static const struct ListNode node3 = {&node2, 3};
  int test() {
    int sum = 0;
    for (const struct ListNode *n = &node3; n != 0; n = n->next)
      sum += n->i;
    return sum;
  }

llvm-svn: 142781

extraneous whitespace. Trying to clean-up this pass as much as I can
before I start making functional changes.

llvm-svn: 142780

llvm-svn: 142779

to bring it under direct test instead of merely indirectly testing it in
the BlockFrequencyInfo pass.

The next step is to start adding tests for the various heuristics
employed, and to start fixing those heuristics once they're under test.

llvm-svn: 142778

These are remainders of the switch to the newer isl version. At the point of
switching I did not test with PoCC support. I should have done. ;-)

llvm-svn: 142777

The recommanded and supported way to use Polly is to load it into clang.
Documentation for this is available on the website under
http://polly.grosser.es/example_load_Polly_into_clang.html

llvm-svn: 142776

This also documents the new option on the website.

llvm-svn: 142775

This removes the separate prevector options for the Pluto and isl scheduler.

llvm-svn: 142774

llvm-svn: 142773

The option -polly-no-optimizer disables the scheduling optimizer.

llvm-svn: 142772

llvm-svn: 142771

llvm-svn: 142770

llvm-svn: 142769

llvm-svn: 142768

llvm-svn: 142767

Similar changes for polly-only-viewer, polly-printer and polly-only-printer.

llvm-svn: 142766

llvm-svn: 142765

llvm-svn: 142764

llvm-svn: 142763

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

llvm-svn: 142760

llvm-svn: 142759

in-class member initialisers).

llvm-svn: 142758

llvm-svn: 142757

llvm-svn: 142756

instead of silently discarding them.

As a side effect, this improves diagnostics for constexpr class
templates slightly.

llvm-svn: 142755

Python.h includes a ton of macros that can cause weird behavior down the road.

llvm-svn: 142754

llvm-svn: 142753

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

llvm-svn: 142752

llvm-svn: 142751

-polly-detect-only=<functionname> allows to limit the scop detection to
a single function.

llvm-svn: 142750

llvm-svn: 142749

llvm-svn: 142748

llvm-svn: 142747

llvm-svn: 142746

llvm-svn: 142745

llvm-svn: 142744

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