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
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
Fix example for VS2012.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206544 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
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
blockfreq: Fixing MSVC after r206548?

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206549 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
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 access to scheduling classes

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206552 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
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
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
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
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
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 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
[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
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
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
[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