llvm-svn: 164008

Use LLVM_DELETED_FUNCTION for copy constructors and copy assignment operators that aren't implemented.

llvm-svn: 164007

Use LLVM_DELETED_FUNCTION for copy constructors and copy assignment operators that aren't implemented.

llvm-svn: 164006

llvm-svn: 164005

llvm-svn: 164004

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: 164002

llvm-svn: 164001

llvm-svn: 164000

llvm-svn: 163999

llvm-svn: 163997

llvm-svn: 163996

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

llvm-svn: 163994

llvm-svn: 163993

llvm-svn: 163992

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

A value that is live in to a basic block should be returned by valueIn()
in LiveRangeQuery(getMBBStartIdx(MBB)), unless it is a PHI-def which
should be returned by valueDefined() instead.

Current code isn't using this functionality. Future code will.

llvm-svn: 163990

headers and modules in more detail. I'd still like to expand on some
of the modules-related issues further, but this is a decent start.

llvm-svn: 163989

llvm-svn: 163988

llvm-svn: 163987

declaration for the entity being documented.

llvm-svn: 163986

'function-like' type that can be annotated with \param.

Thanks to Eli Friedman for noticing!

llvm-svn: 163985

parameters.

llvm-svn: 163984

llvm-svn: 163983

llvm-svn: 163982

UnqualifiedId() properly noncopyable.

llvm-svn: 163981

llvm-svn: 163980

llvm-svn: 163979

llvm-svn: 163978

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

If a PHI value happens to be live out from the layout predecessor of its
def block, the def slot index will be in the middle of the segment:

%vreg11 = [192r,240B:0)[352r,416B:2)[416B,496r:1)  0@192r 1@480B-phi %2@352r

A LiveRangeQuery for 480 should return NULL from valueIn() since the
PHI value is defined at the block entry, not live in to the block.

No test case, future code depends on this functionality.

llvm-svn: 163971

llvm-svn: 163970

llvm-svn: 163969

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

llvm-svn: 163966

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