DebugInfo: Test linkonce-odr functions under LTO.

This was previously regressed/broken by r192749 (reverted due to this
issue in r192938) and I was about to break it again by accident with
some more invasive changes that deal with the subprogram lists. So to
avoid that and further issues - here's a test.

It's a pretty basic test - in both r192749 and my impending case, this
test would crash, but checking the basics (that we put a subprogram in
just one of the two CUs) seems like a good start.

We still get this wrong in weird ways if the linkonce-odr function
happens to not be identical in the metadata (because it's defined in two
different files (hence the # line directives in this test), etc) even
though it meets the language requirements (identical token stream) for
such a thing. That results in two subprogram DIEs, but only one of them
gets the parameter and high/low pc information, etc. We probably need to
use the DIRef infrastructure to deduplicate functions as we do types to
address this issue - or perhaps teach the BC linker to remove the
duplicate entries in subprogram lists?

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209614 91177308-0d34-0410-b5e6-96231b3b80d8
Make the LoopRotate pass's maximum header size configurable both programmatically
and via the command line, mirroring similar functionality in LoopUnroll.  In
situations where clients used custom unrolling thresholds, their intent could
previously be foiled by LoopRotate having a hardcoded threshold.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209617 91177308-0d34-0410-b5e6-96231b3b80d8
[AArch64] Add a regression test for the load store optimizer.

We have a couple of regression tests for load/store pairing, but (to my knowledge) there are no regression tests for the load/store + add/sub folding.

As a first step towards increased test coverage of this area, this commit adds a test for one instance of a load + add to pre-indexed load transformation.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209618 91177308-0d34-0410-b5e6-96231b3b80d8
Remove accidentally committed whitespace.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209619 91177308-0d34-0410-b5e6-96231b3b80d8
AArch64: remove empty ARM64 directories from svn.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209621 91177308-0d34-0410-b5e6-96231b3b80d8
[asan] decrease asan-instrumentation-with-call-threshold from 10000 to 7000, see PR17409

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209623 91177308-0d34-0410-b5e6-96231b3b80d8
[AArch64] Add more regression tests for the load/store optimization pass.

Cover the following cases:

  ldr X, [x0, #32]
   ...
  add x0, x0, #32
   ->
  ldr X, [x0, #32]!

with X being either w1, x1, s0, d0 or q0.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209624 91177308-0d34-0410-b5e6-96231b3b80d8
[AArch64] Add store + add folding regression tests for the load/store optimization pass.

Add tests for the following transform:

 str X, [x0, #32]
  ...
 add x0, x0, #32
  ->
 str X, [x0, #32]!

with X being either w1, x1, s0, d0 or q0.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209627 91177308-0d34-0410-b5e6-96231b3b80d8
Convert a few loops to use ranges.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209628 91177308-0d34-0410-b5e6-96231b3b80d8
Some cleanup for r209568.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209634 91177308-0d34-0410-b5e6-96231b3b80d8
AArch64: simplify calling conventions slightly.

We can eliminate the custom C++ code in favour of some TableGen to
check the same things. Functionality should be identical, except for a
buffer overrun that was present in the C++ code and meant webkit
failed if any small argument needed to be passed on the stack.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209636 91177308-0d34-0410-b5e6-96231b3b80d8
AArch64: force i1 to be zero-extended at an ABI boundary.

This commit is debatable. There are two possible approaches, neither
of which is really satisfactory:

1. Use "@foo(i1 zeroext)" to mean an extension to 32-bits on Darwin,
   and 8 bits otherwise.
2. Redefine "@foo(i1)" to mean that the i1 is extended by the caller
   to 8 bits. This goes against the spirit of "zeroext" I think, but
   it's a bit of a vague construct anyway (by definition you're going
   to extend to the amount required by the ABI, that's why it's the
   ABI!).

This implements option 2. The DAG machinery really isn't setup for the
first (there's a fairly strong assumption that "zeroext" goes to at
least the smallest register size), and even if it was the resulting
DAG looks like it would be inferior in many cases.

Theoretically we could add AssertZext nodes in the consumers of
ABI-passed values too now, but this actually seems to make the code
worse in practice by making truncation proceed in two steps. The code
produced is equally valid if we continue to assume only the low bit is
defined.

Should fix PR19850

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209637 91177308-0d34-0410-b5e6-96231b3b80d8
[PPC] Use alias symbols in address computation.

This seems to match what gcc does for ppc and what every other llvm
backend does.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209638 91177308-0d34-0410-b5e6-96231b3b80d8
Use existing helper function.

No functionality change.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209640 91177308-0d34-0410-b5e6-96231b3b80d8
Convert some X86 blendv* intrinsics into IR.

Summary:
Implemented an InstCombine transformation that takes a blendv* intrinsic
call and translates it into an IR select, if the mask is constant.

This will eventually get lowered into blends with immediates if possible,
or pblendvb (with an option to further optimize if we can transform the
pblendvb into a blend+immediate instruction, depending on the selector).
It will also enable optimizations by the IR passes, which give up on
sight of the intrinsic.

Both the transformation and the lowering of its result to asm got shiny
new tests.

The transformation is a bit convoluted because of blendvp[sd]'s
definition:

Its mask is a floating point value! This forces us to convert it and get
the highest bit. I suppose this happened because the mask has type
__m128 in Intel's intrinsic and v4sf (for blendps) in gcc's builtin.

I will send an email to llvm-dev to discuss if we want to change this or
not.

Reviewers: grosbach, delena, nadav

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209643 91177308-0d34-0410-b5e6-96231b3b80d8
Adding testcase for PR18886.

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209645 91177308-0d34-0410-b5e6-96231b3b80d8
AArch64: support 'c' and 'n' inline asm modifiers.

These are tested by test/CodeGen/Generic, so we should probably know
how to deal with them. Fortunately generic code does it if asked.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209648 91177308-0d34-0410-b5e6-96231b3b80d8
ARM: teach AAPCS-VFP to deal with Cortex-M4.

Cortex-M4 only has single-precision floating point support, so any LLVM
"double" type will have been split into 2 i32s by now. Fortunately, the
consecutive-register framework turns out to be precisely what's needed to
reconstruct the double and follow AAPCS-VFP correctly!

rdar://problem/17012966

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