Add LIS::pruneValue() and extendToIndices(). These two functions are
used by the register coalescer when merging two live ranges requires
more than a trivial value mapping as supported by LiveInterval::join().

The pruneValue() function can remove the part of a value number that is
going to conflict in join(). Afterwards, extendToIndices can restore the
live range, using any new dominating value numbers and updating the SSA
form.

Use this complex value mapping to support merging a register into a
vector lane that has a conflicting value, but the clobbered lane is
undef.

llvm-svn: 164074

These extra operands are not needed by register allocators using
VirtRegRewriter, and RAFast don't need them any longer.

By omitting the <imp-def> operands, it becomes possible for the new
register coalescer to track which lanes are valid and which are undef.

llvm-svn: 164073

I have to work out the Target/CodeGen header dependencies
before putting this back.

llvm-svn: 164072

llvm-svn: 164068

llvm-svn: 164066

llvm-svn: 164065

llvm-svn: 164061

While we are setting the earlier def to true, also make it live.

llvm-svn: 164056

destination in SimplifyCondBranchToCondBranch.

llvm-svn: 164054

we will do that when we implement the full save/restore.

Patch by Reed Kotler.

llvm-svn: 164051

Increase the static sizes of some SmallSets. finalizeBundle() is very frequently called for some backends, and growing into an std::set is overkill for these numbers.

llvm-svn: 164044

llvm-svn: 164043

- Preserve the original NOutVT during casting from vector to integer by
  extracting vector elements.

llvm-svn: 164042

llvm-svn: 164040

LLVM_ATTRIBUTE_USED forces emission of a function. To silence unused function warnings use LLVM_ATTRIBUTE_UNUSED.

llvm-svn: 164036

MSVC8 won't compile lower_bound if one is missing.

llvm-svn: 164035

The cases where no initialization happens should still be checked for logic flaws.

llvm-svn: 164032

llvm-svn: 164030

This is used in the AMDIL and R600 backends.

llvm-svn: 164029

Disable the protection from escaped allocas in an attempt to find violating passes. This may break the buildbots. I plan to revert it in a few hours.

llvm-svn: 164024

partition use lists a bit. No functionality changed.

These visitors are actually visiting a tuple of a Use and an offset into
the alloca. However, we use the InstVisitor to handle the dispatch over
the users, and so the Use and Offset are stored in class member
variables and set just before each call to visit(). This is fairly
awkward and makes the functions a bit harder to read, but its the only
real option we have until InstVisitor can be rewritten to use variadic
templates.

However, this pattern shouldn't be followed on the helper member
functions where there is no interface constraint from the visitor. We
already were passing the instruction as a normal parameter rather than
use the Use to get at it, start passing the offset as well. This will
become more important in subsequent patches as the offset will in some
cases change while visiting a single instruction.

llvm-svn: 164003

llvm-svn: 164001

llvm-svn: 164000

It had patterns for zext-loading and extending. This commit adds patterns for loading a wide type, performing a bitcast,
and extending. This is an odd pattern, but it is commonly used when writing code with intrinsics.

rdar://11897677

llvm-svn: 163995

The live range of an SSA value forms a sub-tree of the dominator tree.
That means the live ranges of two values overlap if and only if the def
of one value lies within the live range of the other.

This can be used to simplify the interference checking a bit: Visit each
def in the two registers about to be joined. Check for interference
against the value that is live in the other register at the def point
only. It is not necessary to scan the set of overlapping live ranges,
this interference check can be done while computing the value mapping
required for the final live range join.

The new algorithm is prepared to handle more complicated conflict
resolution - We can allow overlapping live ranges with different values
as long as the differing lanes are undef or unused in the other
register.

The implementation in this patch doesn't do that yet, it creates code
that is nearly identical to the old algorithm's, except:

- The new stripCopies() function sees through multiple copies while
  the old RegistersDefinedFromSameValue() only can handle one.

- There are a few rare cases where the new algorithm can erase an
  IMPLICIT_DEF instuction that RegistersDefinedFromSameValue() couldn't
  handle.

llvm-svn: 163991

llvm-svn: 163974

llvm-svn: 163973

Kill flags are removed more and more aggressively during the register
allocation passes, it is better to get information from LiveIntervals.

llvm-svn: 163972

llvm-svn: 163970

What we have so far:
- Some clang test failures (these were known already)

- Perf results are mixed, some big regressions
  http://llvm.org/perf/db_default/v4/nts/3844
  http://llvm.org/perf/db_default/v4/nts/3845

  bullet suffers a lot. matmul is interesting: slower scalar code, faster with -vectorize.

- Some dragonegg selfhost bots crash in SROA during selfhost now
  http://lab.llvm.org:8011/builders/dragonegg-x86_64-linux-gcc-4.6-self-host-checks/builds/1632
  http://lab.llvm.org:8011/builders/dragonegg-x86_64-linux-gcc-4.5-self-host/builds/1891

llvm-svn: 163968

This was only an issue if sse is disabled.

llvm-svn: 163967

new one, and add support for running the new pass in that mode and in
that slot of the pass manager. With this the new pass can completely
replace the old one within the pipeline.

The strategy for enabling or disabling the SSAUpdater logic is to do it
by making the requirement of the domtree analysis optional. By default,
it is required and we get the standard mem2reg approach. This is usually
the desired strategy when run in stand-alone situations. Within the
CGSCC pass manager, we disable requiring of the domtree analysis and
consequentially trigger fallback to the SSAUpdater promotion.

In theory this would allow the pass to re-use a domtree if one happened
to be available even when run in a mode that doesn't require it. In
practice, it lets us have a single pass rather than two which was
simpler for me to wrap my head around.

There is a hidden flag to force the use of the SSAUpdater code path for
the purpose of testing. The primary testing strategy is just to run the
existing tests through that path. One notable difference is that it has
custom code to handle lifetime markers, and one of the tests has been
enhanced to exercise that code.

This has survived a bootstrap and the test suite without serious
correctness issues, however my run of the test suite produced *very*
alarming performance numbers. I don't entirely understand or trust them
though, so more investigation is on-going.

To aid my understanding of the performance impact of the new SROA now
that it runs throughout the optimization pipeline, I'm enabling it by
default in this commit, and will disable it again once the LNT bots have
picked up one iteration with it. I want to get those bots (which are
much more stable) to evaluate the impact of the change before I jump to
any conclusions.

NOTE: Several Clang tests will fail because they run -O3 and check the
result's order of output. They'll go back to passing once I disable it
again.

llvm-svn: 163965

use load/store fragments defined in TargetSelectionDAG.td in place of them.
Unaligned loads/stores are either expanded or lowered to target-specific nodes,
so instruction selection should see only aligned load/store nodes.

No changes in functionality.

llvm-svn: 163960

Patch by Reed Kotler.

llvm-svn: 163956

destination.

Updated previous implementation to fix a case not covered:
// PBI: br i1 %x, TrueDest, BB
// BI:  br i1 %y, TrueDest, FalseDest
The other case was handled correctly.
// PBI: br i1 %x, BB, FalseDest
// BI:  br i1 %y, TrueDest, FalseDest

Also tried to use 64-bit arithmetic instead of APInt with scale to simplify the
computation. Let me know if you have other opinions about this.

llvm-svn: 163954

llvm-svn: 163945

case to a conditional branch and when removing dead cases.

llvm-svn: 163942

llvm-svn: 163940

llvm-svn: 163934

llvm-svn: 163933