Stop using the LiveIntervalUnions provided by RegAllocBase, they will be
removed soon.

llvm-svn: 158866

Soon we won't need to compute live intervals for physical registers.

llvm-svn: 158865

Filter out physreg candidates with regunit interferrence.
Also compute regmask interference more efficiently.

llvm-svn: 158864

As Nadav pointed out the first implementation was obscure.

llvm-svn: 158862

llvm-svn: 158858

That is a DenseMap iterator keyed by pointers, so the iteration order is
nondeterministic.

I would like to replace the DenseMap with an IndexedMap which doesn't
allow iteration.

llvm-svn: 158856

llvm-svn: 158855

that are generated by TableGen and are already available in
MipsGenRegisterInfo.inc. Suggested by Jakob Stoklund Olesen.

Also, fix bug in function DecodeAFGR64RegisterClass.

Patch by Vladimir Medic. 

llvm-svn: 158846

llvm-svn: 158844

llvm-svn: 158841

This is supported by gcc and clang, but guarded by a macro for MSVC 2008.

The extern template declaration is not necessary but generally good
form. It can avoid extra instantiations of the template methods
defined inline.

The EXTERN_TEMPLATE_INSTANTIATION macro could probably be generalized to
handle multiple template parameters if someone thinks it's worthwhile.

llvm-svn: 158840

Add users of a MERGE_VALUE node to the worklist to process again when the node is removed.  Sorry, no test case.  Foudn it by inspection of the code

llvm-svn: 158839

Regunit live ranges are computed on demand, so when mi-sched calls
handleMove, some regunits may not have live ranges yet.

That makes updating them easier: Just skip the non-existing ranges. They
will be computed correctly from the rescheduled machine code when they
are needed.

llvm-svn: 158831

replace usage of EmitGEPOffset() with TargetData::getIndexedOffset() when the GEP offset is known to be constant.
With this change, we avoid relying on the IR Builder to constant fold the operations.

No functionality change intended.

llvm-svn: 158829

llvm-svn: 158827

llvm-svn: 158823

The test case for this will come with the PPC indexed preinc loads commit.

llvm-svn: 158822

llvm-svn: 158820

llvm-svn: 158819

llvm-svn: 158818

llvm-svn: 158817

llvm-svn: 158816

llvm-svn: 158815

llvm-svn: 158814

llvm-svn: 158813

llvm-svn: 158810

llvm-svn: 158808

llvm-svn: 158806

llvm-svn: 158805

llvm-svn: 158804

llvm-svn: 158803

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. ;]

llvm-svn: 158800

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.

llvm-svn: 158799

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.

llvm-svn: 158798

llvm-svn: 158797

llvm-svn: 158795

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.

llvm-svn: 158792

-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.

llvm-svn: 158790

llvm-svn: 158789

llvm-svn: 158788