A new algorithm for computing LoopInfo. Temporarily disabled.

-stable-loops enables a new algorithm for generating the Loop
forest. It differs from the original algorithm in a few respects:

- Not determined by use-list order.
- Initially guarantees RPO order of block and subloops.
- Linear in the number of CFG edges.
- Nonrecursive.

I didn't want to change the LoopInfo API yet, so the block lists are
still inclusive. This seems strange to me, and it means that building
LoopInfo is not strictly linear, but it may not be a problem in
practice. At least the block lists start out in RPO order now. In the
future we may add an attribute or wrapper analysis that allows other
passes to assume RPO order.

The primary motivation of this work was not to optimize LoopInfo, but
to allow reproducing performance issues by decomposing the compilation
stages. I'm often unable to do this with the current LoopInfo, because
the loop tree order determines Loop pass order. Serializing the IR
tends to invert the order, which reverses the optimization order. This
makes it nearly impossible to debug interdependent loop optimizations
such as LSR.

I also believe this will provide more stable performance results across time.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158790 91177308-0d34-0410-b5e6-96231b3b80d8
Don't insert 128-bit UNDEF into 256-bit vectors. Just keep the 256-bit vector. Original patch by Elena Demikhovsky. Tweaked by me to allow possibility of covering more cases.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158792 91177308-0d34-0410-b5e6-96231b3b80d8
Add predicate check around some patterns.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158795 91177308-0d34-0410-b5e6-96231b3b80d8
Add predicate check around some patterns.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158797 91177308-0d34-0410-b5e6-96231b3b80d8
Fix inappropriate use of anonymous namespaces in unittests.

The TEST_F macros actually declare *subclasses* of the test fixtures.
Even if they didn't we don't want them to declare external functions.
The entire unit test, including both the fixture class and the fixture
test cases should be wrapped in the anonymous namespace.

This issue was caught by the new '-Winternal-linkage-in-inline' warning.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158798 91177308-0d34-0410-b5e6-96231b3b80d8
Fix two rather subtle internal vs. external linker issues.

I'll admit I'm not entirely satisfied with this change, but it seemed
the cleanest option. Other suggestions quite welcome

The issue is that the traits specializations have static methods which
return the typedef'ed PHI_iterator type. In both the IR and MI layers
this is typedef'ed to a custom iterator class defined in an anonymous
namespace giving the types and the functions returning them internal
linkage. However, because the traits specialization is defined in the
'llvm' namespace (where it has to be, specialized template lives there),
and is in turn used in the templated implementation of the SSAUpdater.
This led to the linkage conflict that Clang now warns about.

The simplest solution to me was just to define the PHI_iterator as
a nested class inside the trait specialization. That way it still
doesn't get scoped widely, it can't be accidentally reused somewhere,
etc. This is a little gross just because nested class definitions are
a little gross, but the alternatives seem more ad-hoc.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158799 91177308-0d34-0410-b5e6-96231b3b80d8
Remove 'static' from inline functions defined in header files.

There is a pretty staggering amount of this in LLVM's header files, this
is not all of the instances I'm afraid. These include all of the
functions that (in my build) are used by a non-static inline (or
external) function. Specifically, these issues were caught by the new
'-Winternal-linkage-in-inline' warning.

I'll try to just clean up the remainder of the clearly redundant "static
inline" cases on functions (not methods!) defined within headers if
I can do so in a reliable way.

There were even several cases of a missing 'inline' altogether, or my
personal favorite "static bool inline". Go figure. ;]

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158800 91177308-0d34-0410-b5e6-96231b3b80d8
Un-indent the list and remove ugly back-slash.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158803 91177308-0d34-0410-b5e6-96231b3b80d8
Unindent list.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158804 91177308-0d34-0410-b5e6-96231b3b80d8
Sphinxify the AliasAnalysis document.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158805 91177308-0d34-0410-b5e6-96231b3b80d8
Unindent list.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158806 91177308-0d34-0410-b5e6-96231b3b80d8
Sphinxify the LTO document.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158808 91177308-0d34-0410-b5e6-96231b3b80d8
Sphinxify BranchWeightMetadata document.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158810 91177308-0d34-0410-b5e6-96231b3b80d8
Sphinxify the lexicon doc.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158813 91177308-0d34-0410-b5e6-96231b3b80d8
Sphinxify the developer policy document.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158814 91177308-0d34-0410-b5e6-96231b3b80d8
Fix the formatting a bit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158815 91177308-0d34-0410-b5e6-96231b3b80d8
Un-indent list to remove ugly back-slash.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158816 91177308-0d34-0410-b5e6-96231b3b80d8
Unindent list.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158817 91177308-0d34-0410-b5e6-96231b3b80d8
Move coding standards reference from development_process.rst to programming.rst.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158818 91177308-0d34-0410-b5e6-96231b3b80d8
Sphinxify the SegmentedStack document.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158819 91177308-0d34-0410-b5e6-96231b3b80d8