[LCG] Fix the bugs that Ben pointed out in code review (and the MSan bot
caught). Sad that we don't have warnings for these things, but bleh, no
idea how to fix that.

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

OnDiskHashTable: Expect the Info type to declare the offset type

This changes the on-disk hash to get the type to use for offsets from
the Info type, so that clients can be more flexible with the size of
table they support.

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

OnDiskHashTable: Expect the Info type to declare the hash size

This changes the on-disk hash to get the size of a hash value from the
Info type, so that clients can be more flexible with the types of hash
they use.

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

[DWARF parser] Respect address ranges specified in compile unit DIE.

When address ranges for compile unit are specified in compile unit DIE
itself, there is no need to collect ranges from children subprogram DIEs.

This change speeds up llvm-symbolizer on Clang-produced binaries with
full debug info. For instance, symbolizing a first address in a 1Gb binary
is now 2x faster (1s vs. 2s).

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

Remove a couple of redundant copies of SmallVector::operator==.

No functionality change.

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

[X86] Improve buildFromShuffleMostly for AVX

For a 256-bit BUILD_VECTOR consisting mostly of shuffles of 256-bit vectors,
both the BUILD_VECTOR and its operands may need to be legalized in multiple
steps.  Consider:

(v8f32 (BUILD_VECTOR (extract_vector_elt (v8f32 %vreg0,) Constant<1>),
                     (extract_vector_elt %vreg0, Constant<2>),
                     (extract_vector_elt %vreg0, Constant<3>),
                     (extract_vector_elt %vreg0, Constant<4>),
                     (extract_vector_elt %vreg0, Constant<5>),
                     (extract_vector_elt %vreg0, Constant<6>),
                     (extract_vector_elt %vreg0, Constant<7>),
                     %vreg1))

a. We can't build a 256-bit vector efficiently so, we need to split it into
two 128-bit vecs and combine them with VINSERTX128.

b. Operands like (extract_vector_elt (v8f32 %vreg0), Constant<7>) needs to be
split into a VEXTRACTX128 and a further extract_vector_elt from the
resulting 128-bit vector.

c. The extract_vector_elt from b. is lowered into a shuffle to the first
element and a movss.

Depending on the order in which we legalize the BUILD_VECTOR and its
operands[1], buildFromShuffleMostly may be faced with:

(v4f32 (BUILD_VECTOR (extract_vector_elt
                      (vector_shuffle<1,u,u,u> (extract_subvector %vreg0, Constant<4>), undef),
                      Constant<0>),
                     (extract_vector_elt
                      (vector_shuffle<2,u,u,u> (extract_subvector %vreg0, Constant<4>), undef),
                      Constant<0>),
                     (extract_vector_elt
                      (vector_shuffle<3,u,u,u> (extract_subvector %vreg0, Constant<4>), undef),
                      Constant<0>),
                     %vreg1))

In order to figure out the underlying vector and their identity we need to see
through the shuffles.

[1] Note that the order in which operations and their operands are legalized is
only guaranteed in the first iteration of LegalizeDAG.

Fixes <rdar://problem/16296956>

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

DebugInfo: Remove some initializer lists to make MSVC happy again.

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

Add range access to MCAssembler's symbol collection.

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

Update comment in LLVMBitCodes.h to reflect the actual bitcode record

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

Fix uint -> size_t conversion warning.

This warning is disabled for the LLVM build,
but external users of the header can still
run into this.

Patch by Ke Bai

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

Revert "blockfreq: Rewrite BlockFrequencyInfoImpl" (#2)

This reverts commit r206622 and the MSVC fixup in r206626.

Apparently the remotely failing tests are still failing, despite my
attempt to fix the nondeterminism in r206621.

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

Fixed llvm-build when no targets are enabled

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

Fixing MSVC after r206622?

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

Better comments to explain buffered/unbuffered processor resources.

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

[DWARF parser] Refactor fetching DIE address ranges.

Add a helper method to get address ranges specified in a DIE
(either by DW_AT_low_pc/DW_AT_high_pc, or by DW_AT_ranges). Use it
to untangle and simplify the code.

No functionality change.

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

Reapply "blockfreq: Rewrite BlockFrequencyInfoImpl"

This reverts commit r206556, effectively reapplying commit r206548 and
its fixups in r206549 and r206550.

In an intervening commit I've added target triples to the tests that
were failing remotely [1] (but passing locally).  I'm hoping the mystery
is solved?  I'll revert this again if the tests are still failing
remotely.

[1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816

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

Add some target triples for better determinism

These tests were failing on some buildbots after r206548 (reverted in
r206556), but passing locally.

They were missing target triples, so maybe that's the problem?

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

LineIterator: Add DataTypes.h for int64_t on MSVC.

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

Add some missing includes for various standard library implementations.

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

Make the copy member of StringRef/ArrayRef generic wrt allocators.

Doesn't make sense to restrict this to BumpPtrAllocator. While there
replace an explicit loop with std::equal. Some standard libraries know
how to compile this down to a ::memcmp call if possible.

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

AArch64/ARM64: add more NEON tests.

Mostly no testing this time, since they were just wrangling
target-specific intrinsics.

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

Allocator: Remove ReferenceAdder hack.

This was a workaround for compilers that had issues with reference
collapsing.

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

ARM64: disable generation of .loh directives outside MachO.

Part of PR19455.

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

ARM64: don't emit .subsections_via_symbols on ELF.

Part of PR19455.

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

ARM64: add extra NEG pattern.

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

AArch64/ARM64: port more AArch64 tests to ARM64.

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

AArch64/ARM64: add non-scalar lowering for more FCVT operations.

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

AArch64/ARM64: improve spotting of EXT instructions from VECTOR_SHUFFLE.

We couldn't cope if the first mask element was UNDEF before, which
isn't ideal.

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

[msan] Add -msan-instrumentation-with-call-threshold.

This flag replaces inline instrumentation for checks and origin stores with
calls into MSan runtime library. This is a workaround for PR17409.

Disabled by default.

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

[LCG] Remove all of the complexity stemming from supporting copying.
Reality is that we're never going to copy one of these. Supporting this
was becoming a nightmare because nothing even causes it to compile most
of the time. Lots of subtle errors built up that wouldn't have been
caught by any "normal" testing.

Also, make the move assignment actually work rather than the bogus swap
implementation that would just infloop if used. As part of that, factor
out the graph pointer updates into a helper to share between move
construction and move assignment.

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

[Allocator] Fix an obvious think-o with the move assignment
implementation of the SpecificBumpPtrAllocator -- we have to actually
move the subobject. =] Noticed when using this code more directly.

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

[LCG] Add support for building persistent and connected SCCs to the
LazyCallGraph. This is the start of the whole point of this different
abstraction, but it is just the initial bits. Here is a run-down of
what's going on here. I'm planning to incorporate some (or all) of this
into comments going forward, hopefully with better editing and wording.
=]

The crux of the problem with the traditional way of building SCCs is
that they are ephemeral. The new pass manager however really needs the
ability to associate analysis passes and results of analysis passes with
SCCs in order to expose these analysis passes to the SCC passes. Making
this work is kind-of the whole point of the new pass manager. =]

So, when we're building SCCs for the call graph, we actually want to
build persistent nodes that stick around and can be reasoned about
later. We'd also like the ability to walk the SCC graph in more complex
ways than just the traditional postorder traversal of the current CGSCC
walk. That means that in addition to being persistent, the SCCs need to
be connected into a useful graph structure.

However, we still want the SCCs to be formed lazily where possible.

These constraints are quite hard to satisfy with the SCC iterator. Also,
using that would bypass our ability to actually add data to the nodes of
the call graph to facilite implementing the Tarjan walk. So I've
re-implemented things in a more direct and embedded way. This
immediately makes it easy to get the persistence and connectivity
correct, and it also allows leveraging the existing nodes to simplify
the algorithm. I've worked somewhat to make this implementation more
closely follow the traditional paper's nomenclature and strategy,
although it is still a bit obtuse because it isn't recursive, using
an explicit stack and a tail call instead, and it is interruptable,
resuming each time we need another SCC.

The other tricky bit here, and what actually took almost all the time
and trials and errors I spent building this, is exactly *what* graph
structure to build for the SCCs. The naive thing to build is the call
graph in its newly acyclic form. I wrote about 4 versions of this which
did precisely this. Inevitably, when I experimented with them across
various use cases, they became incredibly awkward. It was all
implementable, but it felt like a complete wrong fit. Square peg, round
hole. There were two overriding aspects that pushed me in a different
direction:

1) We want to discover the SCC graph in a postorder fashion. That means
   the root node will be the *last* node we find. Using the call-SCC DAG
   as the graph structure of the SCCs results in an orphaned graph until
   we discover a root.

2) We will eventually want to walk the SCC graph in parallel, exploring
   distinct sub-graphs independently, and synchronizing at merge points.
   This again is not helped by the call-SCC DAG structure.

The structure which, quite surprisingly, ended up being completely
natural to use is the *inverse* of the call-SCC DAG. We add the leaf
SCCs to the graph as "roots", and have edges to the caller SCCs. Once
I switched to building this structure, everything just fell into place
elegantly.

Aside from general cleanups (there are FIXMEs and too few comments
overall) that are still needed, the other missing piece of this is
support for iterating across levels of the SCC graph. These will become
useful for implementing #2, but they aren't an immediate priority.

Once SCCs are in good shape, I'll be working on adding mutation support
for incremental updates and adding the pass manager that this analysis
enables.

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

X86: Pattern match scalar loads + vcvtph2ps into just vcvtph2ps.

vcvtph2ps only reads the lower 64 bits of the address passed to the
intrinsic.

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

Revert r206565 (and r206566 which updated tests).

This commit was attributed to a different person from the person who
posted the patch to the list, and the person who posted it the list
claimed when they did that they were not the author, but that the author
was yet a third person. I don't know what is going on here, but
reverting until the attribution is clear and the author has explicitly
contributed the patch.

Also, the review hasn't really involved any of the MC maintainers and
that seems questionable too.

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

AArch64/ARM64: port atomics test to ARM64.

Covers quite a few extra instructions (like any of the max/min ones
which were broken until recently on ARM64).

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

AArch64/ARM64: spot a greater variety of concat_vector operations.

Code mostly copied from AArch64, just tidied up a trifle and plumbed
into the ARM64 way of doing things.

This also enables the AArch64 tests which inspired the previous
untested commits.

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

ARM64: implement cunning optimisation from AArch64

A vector extract followed by a dup can become a single instruction even if the
types don't match. AArch64 handled this in ISelLowering, but a few reasonably
simple patterns can take care of it in TableGen, so that's where I've put it.

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

ARM64: spot a vector_shuffle that maps to INS and expand.

Tests will be coming very shortly when all the optimisations needed to
support AArch64's neon-copy.ll file are committed.

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

ARM64: nick some AArch64 patterns for extract/insert -> INS.

Tests will be committed shortly when all optimisations needed to
support AArch64's neon-copy.ll file are supported.

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

AArch64/ARM64: emit all vector FP comparisons as such.

ARM64 was scalarizing some vector comparisons which don't quite map to
AArch64's compare and mask instructions. AArch64's approach of sacrificing a
little efficiency to emulate them with the limited set available was better, so
I ported it across.

More "inspired by" than copy/paste since the backend's internal expectations
were a bit different, but the tests were invaluable.

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

AArch64/ARM64: port BSL logic from AArch64 & enable test.

I enhanced it a little in the process. The decision shouldn't really be beased
on whether a BUILD_VECTOR is a splat: any set of constants will do the job
provided they're related in the correct way.

Also, the BUILD_VECTOR could be any operand of the incoming AND nodes, so it's
best to check for all 4 possibilities rather than assuming it'll be the RHS.

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

AArch64/ARM64: copy byval implementation from AArch64.

It's not actually used to handle C or C++ ABI rules on ARM64, but could well be
emitted by other language front-ends, so it's as well to have a sensible
implementation.

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

Add missing config file for newly added test case introduced by r206563.

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

Updated test with register names following r206565.

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

Patch by Ray Donnelly.

Emit WIN64 SEH registers by name instead of just number.

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

[asan] one more workaround for PR17409: don't do BB-level coverage instrumentation if there are more than N (=1500) basic blocks. This makes ASanCoverage work on libjpeg_turbo/jchuff.c used by Chrome, which has 1824 BBs

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

This commit allows vectorized loops to be unrolled by a factor of 2 for AArch64.
A new test case is also added for ARM64.

Patched by Z.Zheng

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

R600: Minor cleanups.

Fix indentation, better line wrapping, unused includes.

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

[ExecutionEngine] Allow JIT clients to enable/disable module verification.

Previously module verification was always enabled, with no way to turn it off.
As of this commit, module verification is on by default in Debug builds, and off
by default in release builds. The default behaviour can be overridden by calling
setVerifyModules(bool) on the JIT instance (this works for both the old JIT, and
MCJIT).

<rdar://problem/16150008>

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

This is one of the optimizations ported from ARM64 to AArch64 to address the performance gap between these two back ends. The test case newly added for AArch64 already exists in ARM64.

Patched by Z.Zheng

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

R600/SI: Try to use scalar BFE.

Use scalar BFE with constant shift and offset when possible.
This is complicated by the fact that the scalar version packs
the two operands of the vector version into one.

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

This commit enables unaligned memory accesses of vector types on AArch64 back end. This should boost vectorized code performance.

Patched by Z. Zheng

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

Revert "blockfreq: Rewrite BlockFrequencyInfoImpl"

This reverts commits r206548, r206549 and r206549.

There are some unit tests failing that aren't failing locally [1], so
reverting until I have time to investigate.

[1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816

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

OnDiskHashTable: Provide iterator_range for keys and data

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

blockfreq: Really fix r206548 (and r206549)

Turns out this code is dead.

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

c++11: Tidy up tblgen w/ range loops.

IntrInfoEmitter cleanup.

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

iterator access to scheduling classes

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

iterator_range accessor for CodeGenTarget instruction list.

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

iterator based accessors for CodeGenInstruction operand list.

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

blockfreq: Fixing MSVC after r206548?

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

blockfreq: Rewrite BlockFrequencyInfoImpl

Rewrite the shared implementation of BlockFrequencyInfo and
MachineBlockFrequencyInfo entirely.

The old implementation had a fundamental flaw:  precision losses from
nested loops (or very wide branches) compounded past loop exits (and
convergence points).

The @nested_loops testcase at the end of
test/Analysis/BlockFrequencyAnalysis/basic.ll is motivating.  This
function has three nested loops, with branch weights in the loop headers
of 1:4000 (exit:continue).  The old analysis gives non-sensical results:

    Printing analysis 'Block Frequency Analysis' for function 'nested_loops':
    ---- Block Freqs ----
     entry = 1.0
     for.cond1.preheader = 1.00103
     for.cond4.preheader = 5.5222
     for.body6 = 18095.19995
     for.inc8 = 4.52264
     for.inc11 = 0.00109
     for.end13 = 0.0

The new analysis gives correct results:

    Printing analysis 'Block Frequency Analysis' for function 'nested_loops':
    block-frequency-info: nested_loops
     - entry: float = 1.0, int = 8
     - for.cond1.preheader: float = 4001.0, int = 32007
     - for.cond4.preheader: float = 16008001.0, int = 128064007
     - for.body6: float = 64048012001.0, int = 512384096007
     - for.inc8: float = 16008001.0, int = 128064007
     - for.inc11: float = 4001.0, int = 32007
     - for.end13: float = 1.0, int = 8

Most importantly, the frequency leaving each loop matches the frequency
entering it.

The new algorithm leverages BlockMass and PositiveFloat to maintain
precision, separates "probability mass distribution" from "loop
scaling", and uses dithering to eliminate probability mass loss.  I have
unit tests for these types out of tree, but it was decided in the review
to make the classes private to BlockFrequencyInfoImpl, and try to shrink
them (or remove them entirely) in follow-up commits.

The new algorithm should generally have a complexity advantage over the
old.  The previous algorithm was quadratic in the worst case.  The new
algorithm is still worst-case quadratic in the presence of irreducible
control flow, but it's linear without it.

The key difference between the old algorithm and the new is that control
flow within a loop is evaluated separately from control flow outside,
limiting propagation of precision problems and allowing loop scale to be
calculated independently of mass distribution.  Loops are visited
bottom-up, their loop scales are calculated, and they are replaced by
pseudo-nodes.  Mass is then distributed through the function, which is
now a DAG.  Finally, loops are revisited top-down to multiply through
the loop scales and the masses distributed to pseudo nodes.

There are some remaining flaws.

  - Irreducible control flow isn't modelled correctly.  LoopInfo and
    MachineLoopInfo ignore irreducible edges, so this algorithm will
    fail to scale accordingly.  There's a note in the class
    documentation about how to get closer.  See also the comments in
    test/Analysis/BlockFrequencyInfo/irreducible.ll.

  - Loop scale is limited to 4096 per loop (2^12) to avoid exhausting
    the 64-bit integer precision used downstream.

  - The "bias" calculation proposed on llvmdev is *not* incorporated
    here.  This will be added in a follow-up commit, once comments from
    this review have been handled.

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

R600/SI: Match sign_extend_inreg to s_sext_i32_i8 and s_sext_i32_i16

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

Fix example for VS2012.

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

PMBuilder: Expose an option to disable tail calls

Adds API to allow frontends to disable tail calls in PassManagerBuilder.

<rdar://problem/16050591>

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

R600/SI: Use SReg_64 instead of VSrc_64 when selecting BUILD_PAIR

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

[ARM64,C++11] Range'ify another loop.

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

Fix bug 19437 - Only add discriminators for DWARF 4 and above.

Summary:
This prevents the discriminator generation pass from triggering if
the DWARF version being used in the module is prior to 4.

Reviewers: echristo, dblaikie

CC: llvm-commits
Differential Revision: http://reviews.llvm.org/D3413

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

remove some dead code

 lib/Analysis/IPA/InlineCost.cpp         |   18 ------------------
 lib/Analysis/RegionPass.cpp             |    1 -
 lib/Analysis/TypeBasedAliasAnalysis.cpp |    1 -
 lib/Transforms/Scalar/LoopUnswitch.cpp  |   21 ---------------------
 lib/Transforms/Utils/LCSSA.cpp          |    2 --
 lib/Transforms/Utils/LoopSimplify.cpp   |    6 ------
 utils/TableGen/AsmWriterEmitter.cpp     |   13 -------------
 utils/TableGen/DFAPacketizerEmitter.cpp |    7 -------
 utils/TableGen/IntrinsicEmitter.cpp     |    2 --
 9 files changed, 71 deletions(-)

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

Start pushing changes for Mips Fast-Isel

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

Make test/CodeGen/ARM64/vector-insertion.ll explicitly select neon syntax

Change the command line vector-insertion.ll to explicitly set the neon syntax
to apple so that buildbots that default to other syntaxes won't fail.

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

R600: Add comment clariying use of sext for result of MUL_U24

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

R600/SI: Stop using i128 as the resource descriptor type

Having i128 as a legal type complicates the legalization phase.  v4i32
is already a legal type, so we will use that instead.

This fixes several piglit tests.

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

R600/SI: Change default register class for i32 to SReg_32

SIFixSGPRCopies is smart enough to handle this now.

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

R600/SI: Teach SIInstrInfo::moveToVALU() how to handle PHI instructions

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

R600/SI: Legalize operands after changing dst reg in FixSGPRCopies

Otherwise we may not legalize some illegal REG_SEQUENCE instructions.

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

Improve ARM64 vector creation

This patch improves the performance of vector creation in caseiswhere where
several of the lanes in the vector are a constant floating point value. It
also includes new patterns to fold together some of the instructions when the
value is 0.0f. Test cases included.

rdar://16349427

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

ARM64: [su]xtw use W regs as inputs, not X regs.

Update the SXT[BHW]/UXTW instruction aliases and the shifted reg addressing
mode handling.

PR19455 and rdar://16650642

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

ManagedStatic is never built with a null constructor, remove support for it.

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

ARM64: switch to IR-based atomic operations.

Goodbye code!

(Game: spot the bug fixed by the change).

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

ARM64: add acquire/release versions of the existing atomic intrinsics.

These will be needed to support IR-level lowering of atomic
operations.

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

Reverse 206485.

After some discussions the preferred semantics of
the always_inline attribute is
inline always when the compiler can determine
that it it safe to do so.

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

[stack protector] Make the StackProtector pass respect ssp-buffer-size.

Previously, SSPBufferSize was assigned the value of the "stack-protector-buffer-size"
attribute after all uses of SSPBufferSize.  The effect was that the default
SSPBufferSize was always used during analysis.  I moved the check for the
attribute before the analysis; now --param ssp-buffer-size= works correctly again.

Differential Revision: http://reviews.llvm.org/D3349

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

Atomics: promote ARM's IR-based atomics pass to CodeGen.

Still only 32-bit ARM using it at this stage, but the promotion allows
direct testing via opt and is a reasonably self-contained patch on the
way to switching ARM64.

At this point, other targets should be able to make use of it without
too much difficulty if they want. (See ARM64 commit coming soon for an
example).

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

C++11: Compatibility with (C++03 => MSVC)

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

C++11: Document some limitations imposed by MSVC

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

R600/SI: f64 frint is legal on CI

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

[AArch64] Implement the getCSRFirstUseCost API, mirroring that in ARM64.

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

Inliner::OptimizationRemark: Fix crash in clang/test/Frontend/optimization-remark.c on some hosts, including --vg.

DebugLoc in Callsite would not live after Inliner. It should be copied before Inliner.

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

[LCG] Remove a dead declaration. This stopped being used when I switched
to a more normal move operation on the graph itself. The definition
already got removed, but I missed the declaration.

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

[LCG] Move the call graph node class into the graph class's definition.
This will become necessary to build up the SCC iterators and SCC
definitions. Moving it now so that subsequent diffs are incremental.

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

Make the User::value_op_iterator a random access iterator. I had written
this code ages ago and lost track of it. Seems worth doing though --
this thing can get called from places that would benefit from knowing
that std::distance is O(1). Also add a very fledgeling unittest for
Users and make sure various aspects of this seem to work reasonably.

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

[LCG] Just move the allocator (now that we can) when moving a call
graph. This simplifies the custom move constructor operation to one of
walking the graph and updating the 'up' pointers to point to the new
location of the graph. Switch the nodes from a reference to a pointer
for the 'up' edge to facilitate this.

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

[LCG] Remove the Module reference member which we weren't using for
anything and doesn't make sense if assigning.

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

[Allocator] Make SpecificBumpPtrAllocator also movable and move
assignable.

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

[X86] Add disassembler support for the 0x0f 0x7f form of movq %mm, %mm.

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

objdump: identify WoA WinCOFF/ARM correctly

Since LLVM currently only supports WinCOFF, assume that the input is WinCOFF
rather than another type of COFF file (ECOFF/XCOFF).  If the architecture is
detected as thumb (e.g. the file has a IMAGE_FILE_MACHINE_ARMNT magic) then use
a triple of thumbv7-windows.

This allows for objdump to properly handle WoA object files without having to
specify the target triple manually.

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

MC: rework static_assert to be MSVC compatible

Visual Studio does not permit referencing a structure member as a static field
for sizeof calculations.  Resort to a pointer cast which is compatible across
Visual Studio and other compilers.

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

Support: Move OnDiskHashTable from clang to llvm

This introduces clang's Basic/OnDiskHashTable.h into llvm as
Support/OnDiskHashTable.h. I've taken the opportunity to add doxygen
comments and run the file through clang-format, but other than the
namespace changing from clang:: to llvm:: the API is identical.

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

R600/SI: Fix zext from i1 to i64

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

[ARM64] Fix "Cannot select" for vector ctpop

The commit of r205855:

Author: Arnold Schwaighofer <aschwaighofer@apple.com>
Date:   Wed Apr 9 14:20:47 2014 +0000

    SLPVectorizer: Only vectorize intrinsics whose operands are widened equally

    The vectorizer only knows how to vectorize intrinics by widening all operands by
    the same factor.

    Patch by Tyler Nowicki!

exposed a backend bug causing a regression (Cannot select ctpop).

The commit msg is a bit confusing because the patch actually changes the
behavior for the loop-vectorizer as well.  As things got refactored into a
helper ctpop got snuck in to the trivially-vectorizable helper which is now
used by both vectorizers.  In other words, we started seeing vector-ctpops in
the backend.

This change makes ctpop LegalizeAction::Expand for the types not supported by
the byte-only CNT instruction.  We may be able to custom-lower these later to
a single CNT but this is to fix the compiler crash first.

Fixes <rdar://problem/16578951>

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