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

lit config.

llvm-svn: 163928

llvm-svn: 163926

llvm-svn: 163922

This models the A9 processor at the level of instruction operands, as
opposed to the itinerary, which models each operation at the level of
pipeline stages.

The two primary motivations are:

1) Allow MachineScheduler to model A9 as an out-of-order processor. It
can now distinguish between hazards that force interlocking vs.
buffered resources.

2) Reduce long-term maintenance by allowing the itinerary and target
hooks to eventually be removed. Note that almost all of the complexity
in the new model exists to model instruction variants, which the
itinerary cannot handle. Instead the scheduler previously relied on
processor-specific target hooks which are incomplete and buggy.

llvm-svn: 163921

the default target of the first switch is not the basic block the second switch
is in (PredDefault != BB).

llvm-svn: 163916

llvm-svn: 163915

This patch introduces a possibility for Hexagon MI scheduler
to perform some target specific post- processing on the scheduling
DAG prior to scheduling.

llvm-svn: 163903

* wrap code blocks in \code ... \endcode;
* refer to parameter names in paragraphs correctly (\arg is not what most
  people want -- it starts a new paragraph);
* use \param instead of \arg to document parameters in order to be consistent
  with the rest of the codebase.

llvm-svn: 163902

The NDEBUG hack is ugly, but I see no better solution.

llvm-svn: 163900

clang warned about this being unused in Release builds.

llvm-svn: 163899

pointless checks in here, bad asserts, and just confusing code. I've
also added a bit more to the comment to clarify what this function is
really trying to do as it was not obvious to Duncan when studying it.

Thanks to Duncan for helping me dig through the issue.

No real functionality changed here in practical cases, and certainly no
test case. This is just cleanup spotted by inspection.

llvm-svn: 163897

explicit check before recursing. A simplification requested by Duncan
during review.

llvm-svn: 163896

inspection by Duncan during review. My suspicion is that we would still
have returned 0 anyways in this case, but doing it sooner is better.

llvm-svn: 163895

deeply suspicious and likely to go away eventually. Also fix a bogus
comment about one of the checks in the vector GEP analysis. Based on
review from Duncan.

llvm-svn: 163894

Originally I had anticipated needing to thread this through more bits of
the SROA pass itself, but that ended up not happening. In the end, this
is a much simpler way to manange the variable.

llvm-svn: 163893

forget from Duncan's review as a FIXME.

llvm-svn: 163892

unexpectedly in the future. More fixes from his code review.

llvm-svn: 163891

being busy testing this...

llvm-svn: 163890

llvm-svn: 163889

llvm-svn: 163888

llvm-svn: 163887

llvm-svn: 163886

llvm-svn: 163885