Fix unused-function warning differently from r220853

Rather than executing this code only needed for an assertion even in a
non-asserts build, just roll the function into the assert. The assertion
text literally describes the two cases so it doesn't seem like this
benefits much from having a separate function (& have to hassle about
ifndef NDEBUG it out, etc)
Remove the wrongly named and now empty Ocaml directory
Fix ARM HVA classification of classes with non-virtual bases

Reuse the PPC64 HVA detection algorithm for ARM and AArch64. This is a
nice code deduplication, since they are roughly identical. A few virtual
method extension points are needed to understand how big an HVA can be
and what element types it can have for a given architecture.

Also make the record expansion code work in the presence of non-virtual
bases.

Reviewed By: uweigand, asl

Differential Revision: http://reviews.llvm.org/D6045
[asan] fix caller-calee instrumentation to emit new cache for every call site
Fix the build
[asan] run-time part of the caller-callee coverage instrumentation
[analyzer] Rename NewDeleteLeaks checker in the test script.

Fixup to r220289.
clang-format: [js] Updates to Google's JavaScript style.

The style guide is changing..
[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>
- Use "for_expression" rather than "allow_unknownanytype"
  to indicate that we're doing stuff for the expression
  parser.

- When for_expression is true, look through @s and find
  the actual class rather than just returning id.

- Rename BuildObjCObjectType to BuildObjCObjectPointerType
  since it's actually returning an object *pointer* type.
- Fixed a bug where ::Describe for class descriptors
  would fail if the class had no ivars.

- Updated use of the RealizeType API by the class
  descriptors to use "for_expression" rather than
  the misnamed "allow_unknownanytype."
Updated the Objective-C runtime type vendor to
load ivars into classes that are reported to the
Objective-C runtime.
In ValueObjectDynamicValue, trust what comes from
the runtime rather than trying to fix it up,
because now those types have ivars regardless of
whether they come from "frame variable" or from
expressions.

Patch by Enrico Granata.
commit on behalf of Oleksiy Vyalov Fix junk content handling within GDBRemoteCOmmunication::CheckForPacket  1. Avoid removing of an extra symbol from m_bytes.  2. iterate over m_bytes until useful content is found.  Differential Revision: http://reviews.llvm.org/D6042
clang-format: [Java] Improve line breaks around annotations.

Before:
  @SomeAnnotation("With some really looooooooooooooong text") private static final
      long something = 0L;

  void SomeFunction(@Nullable
                    String something) {}

After:
  @SomeAnnotation("With some really looooooooooooooong text")
  private static final long something = 0L;

  void SomeFunction(@Nullable String something) {}
[asan] do not treat inline asm calls as indirect calls
ignore -mconstructor-aliases when adding field paddings for asan

Summary:
When we are adding field paddings for asan even an empty dtor has to remain in the code,
so we ignore -mconstructor-aliases if the paddings are going to be added.

Test Plan: added a test

Reviewers: rsmith, rnk, rafael

Reviewed By: rafael

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D6038
[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>!
[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.
[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
performs the necessary enablement in the front end, and tests it by
implementing intrinsics for minimum and maximum using the vector
double data type.

The main change in the front end is to no longer disallow "vector" and
"double" in the same declaration (lib/Sema/DeclSpec.cpp), but "vector"
and "long double" must still be disallowed.  The new intrinsics are
accessed via vec_max and vec_min with changes in
lib/Headers/altivec.h.  Note that for v4f32, we already access
corresponding VMX builtins, but with VSX enabled we should use the
forms that allow all 64 vector registers.

The new built-ins are defined in include/clang/Basic/BuiltinsPPC.def.

I've added a new test in test/CodeGen/builtins-ppc-vsx.c that is
similar to, but much smaller than, builtins-ppc-altivec.c.  This
allows us to test VSX IR generation without duplicating CHECK lines
for the existing bazillion Altivec tests.

Since vector double is now legal when VSX is available, I've modified
the error message, and changed where we test for it and for vector
long double, since the target machine isn't visible in the old place.
This serendipitously removed a not-pertinent warning about 'long'
being deprecated when used with 'vector', when "vector long double" is
encountered and we just want to issue an error.  The existing tests
test/Parser/altivec.c and test/Parser/cxx-altivec.cpp have been
updated accordingly, and I've added test/Parser/vsx.c to verify that
"vector double" is now legitimate with VSX enabled.

There is a companion patch for LLVM.