[CodeGenPrepare] Move extractelement close to store if they can be combined.

This patch adds an optimization in CodeGenPrepare to move an extractelement
right before a store when the target can combine them.
The optimization may promote any scalar operations to vector operations in the
way to make that possible.


** Context **

Some targets use different register files for both vector and scalar operations.
This means that transitioning from one domain to another may incur copy from one
register file to another. These copies are not coalescable and may be expensive.
For example, according to the scheduling model, on cortex-A8 a vector to GPR
move is 20 cycles.


** Motivating Example **

Let us consider an example:
define void @foo(<2 x i32>* %addr1, i32* %dest) {
 %in1 = load <2 x i32>* %addr1, align 8
 %extract = extractelement <2 x i32> %in1, i32 1
 %out = or i32 %extract, 1
 store i32 %out, i32* %dest, align 4
 ret void
}

As it is, this IR generates the following assembly on armv7:
  vldr  d16, [r0]            @vector load  
  vmov.32 r0, d16[1]  @ cross-register-file copy: 20 cycles
  orr r0, r0, #1           @ scalar bitwise or
  str r0, [r1]               @ scalar store
  bx  lr

Whereas we could generate much faster code:
  vldr  d16, [r0]               @ vector load
  vorr.i32  d16, #0x1     @ vector bitwise or
  vst1.32 {d16[1]}, [r1:32] @ vector extract + store
  bx  lr

Half of the computation made in the vector is useless, but this allows to get
rid of the expensive cross-register-file copy.


** Proposed Solution **

To avoid this cross-register-copy penalty, we promote the scalar operations to
vector operations. The penalty will be removed if we manage to promote the whole
chain of computation in the vector domain.
Currently, we do that only when the chain of computation ends by a store and the
target is able to combine an extract with a store.

Stores are the most likely candidates, because other instructions produce values
that would need to be promoted and so, extracted as some point[1]. Moreover,
this is customary that targets feature stores that perform a vector extract (see
AArch64 and X86 for instance).

The proposed implementation relies on the TargetTransformInfo to decide whether
or not it is beneficial to promote a chain of computation in the vector domain.
Unfortunately, this interface is rather inaccurate for this level of details and
although this optimization may be beneficial for X86 and AArch64, the inaccuracy
will lead to the optimization being too aggressive.
Basically in TargetTransformInfo, everything that is legal has a cost of 1,
whereas, even if a vector type is legal, usually a vector operation is slightly
more expensive than its scalar counterpart. That will lead to too many
promotions that may not be counter balanced by the saving of the
cross-register-file copy. For instance, on AArch64 this penalty is just 4
cycles.

For now, the optimization is just enabled for ARM prior than v8, since those
processors have a larger penalty on cross-register-file copies, and the scope is
limited to basic blocks. Because of these two factors, we limit the effects of
the inaccuracy. Indeed, I did not want to build up a fancy cost model with block
frequency and everything on top of that.

[1] We can imagine targets that can combine an extractelement with  other
instructions than just stores. If we want to go into that direction, the current
interfaces must be augmented and, moreover, I think this becomes a global isel
problem.

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

<rdar://problem/14170854>


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220978 91177308-0d34-0410-b5e6-96231b3b80d8
[asan] do not treat inline asm calls as indirect calls

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220985 91177308-0d34-0410-b5e6-96231b3b80d8
[AArch64] Check Dest Register Liveness in CondOpt pass.

Our internal test reveals such case should not be transformed:

  cmp x17, #3
  b.lt .LBB10_15
  ...
  subs x12, x12, #1
  b.gt .LBB10_1

where x12 is a liveout, becomes:

  cmp x17, #2
  b.le .LBB10_15
  ...
  subs x12, x12, #2
  b.ge .LBB10_1

Unable to provide test case as it's difficult to reproduce on community branch.

http://reviews.llvm.org/D6048
Patch by Zhaoshi Zheng <zhaoshiz@codeaurora.org>!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220987 91177308-0d34-0410-b5e6-96231b3b80d8
[PowerPC] Initial VSX intrinsic support, with min/max for vector double

Now that we have initial support for VSX, we can begin adding
intrinsics for programmer access to VSX instructions.  This patch adds
basic support for VSX intrinsics in general, and tests it by
implementing intrinsics for minimum and maximum for the vector double
data type.

The LLVM portion of this is quite straightforward.  There is a
companion patch for Clang.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220988 91177308-0d34-0410-b5e6-96231b3b80d8
IR: MDNode => Value: Instruction::setMetadata()

Change `Instruction::setMetadata()` API to accept `Value` instead of
`MDNode`.  Part of PR21433.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220994 91177308-0d34-0410-b5e6-96231b3b80d8
IR: Instruction::setMetadata() should use cast_or_null

Not sure why this assertion didn't fire locally [1], but in r220994
`Instruction::setMetadata()` should be using `cast_or_null`.

[1]: http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/12327

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220995 91177308-0d34-0410-b5e6-96231b3b80d8
R600: Make sure to inline all internal functions

Function calls aren't supported yet.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220996 91177308-0d34-0410-b5e6-96231b3b80d8
R600: Don't promote allocas when one of the users is a ptrtoint instruction

We need to figure out how to track ptrtoint values all the
way until result is converted back to a pointer in order
to correctly rewrite the pointer type.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220997 91177308-0d34-0410-b5e6-96231b3b80d8
R600: Add missing file to CMakeLists.txt

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220998 91177308-0d34-0410-b5e6-96231b3b80d8
[Object] Modify OwningBinary's interface to separate inspection from ownership.

The getBinary and getBuffer method now return ordinary pointers of appropriate
const-ness. Ownership is transferred by calling takeBinary(), which returns a
pair of the Binary and a MemoryBuffer.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221003 91177308-0d34-0410-b5e6-96231b3b80d8
R600: Add IPO to the list of required libraries

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221004 91177308-0d34-0410-b5e6-96231b3b80d8
Sink most of DwarfDebug::constructAbstractSubprogramScopeDIE into DwarfCompileUnit

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221005 91177308-0d34-0410-b5e6-96231b3b80d8
Correctly update dom-tree after loop vectorizer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221009 91177308-0d34-0410-b5e6-96231b3b80d8
Sink some of DwarfDebug::collectDeadVariables down into DwarfCompileUnit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221010 91177308-0d34-0410-b5e6-96231b3b80d8
Suppress MSVC's equivalent of -Wshadow warnings

IMO we need to clean up some of these, but the member variable one
(C4458) has false positives on static methods.  It is currently firing
on Twine, which has a static method like:
  struct Twine {
    uintptr_t LHS, RHS;
    static void staticMethod() {
      // warning C4458: declaration of 'LHS' hides class member
      uintptr_t LHS;
      ...
    }
  };

We should fix up clang's -Wshadow and clean it up, and then we can
re-enable some of these MSVC warnings.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221012 91177308-0d34-0410-b5e6-96231b3b80d8
Define LLVM_NOEXCEPT with MSVC 14 CTP 3 or newer

We have to use _MSC_FULL_VER here as CTP 2 and earlier didn't define
noexcept to my knowledge.

Fixes build error in lib/Support/Error.cpp when inheriting from
std::error_category, which has a noexcept virtual method.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221013 91177308-0d34-0410-b5e6-96231b3b80d8
Refactor duplicated code in liking GlobalValues.

There is quiet a bit of logic that is common to any GlobalValue but was
duplicated for Functions, GlobalVariables and GlobalAliases.

While at it, merge visibility even when comdats are used, fixing pr21415.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221014 91177308-0d34-0410-b5e6-96231b3b80d8
Work around bugs in MSVC "14" CTP 3's conversion logic

It appears to ignore or find ambiguous MachineInstrBuilder's conversion
operators that allow conversion to MachineInstr* and
MachineBasicBlock::bundle_iterator.

As a workaround, add an explicit way to get the MachineInstr.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221017 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "R600: Make sure to inline all internal functions"

This reverts commit r220996.

It introduced layering violations causing link errors in many
configurations.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221020 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "R600: Add missing file to CMakeLists.txt"

This reverts commit r220998.

It should've been reverted with the other change.

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