This restores the commit from SVN r219899 with an additional change to ensure
that the CodeGen is correct for the case that was identified as being incorrect
(originally PR7272).

In the case that during inlining we need to synthesize a value on the stack
(i.e. for passing a value byval), then any function involving that alloca must
be stripped of its tailness as the restriction that it does not access the
parent's stack no longer holds.  Unfortunately, a single alloca can cause a
rippling effect through out the inlining as the value may be aliased or may be
mutated through an escaped external call.  As such, we simply track if an alloca
has been introduced in the frame during inlining, and strip any tail calls.

llvm-svn: 220811

When trying to get the element type of an array type, do not go to the canonical type, since that will strip typedefs where we want them to be preserved. Fixes rdar://15453076

llvm-svn: 220810

No functional change

llvm-svn: 220808

llvm-svn: 220807

Refactored through AVX512_maskable

llvm-svn: 220806

Before:
  template <class T, class = typename std::enable_if<std::is_integral<
                         T>::value &&(sizeof(T) > 1 || sizeof(T) < 8)>::type>
  void F();

After:
  template <class T, class = typename std::enable_if<
                         std::is_integral<T>::value &&
                         (sizeof(T) > 1 || sizeof(T) < 8)>::type>
  void F();

llvm-svn: 220805

llvm-svn: 220804

llvm-svn: 220803

llvm-svn: 220802

Before:
  ReturnType MACRO
      FunctionName() {}

After:
  ReturnType MACRO
  FunctionName() {}

This fixes llvm.org/PR21404.

I wonder what the motivation for that if-condition was. But as no test
breaks, ...

llvm-svn: 220801

llvm-svn: 220787

llvm-svn: 220786

PR21367: Don't accept rvalue references as an extension in C++98 mode if we're in a new-type-id or conversion-type-id, since those things can legitimately be followed by a binary && operator.

llvm-svn: 220785

Apparently, people are very much divided on what the "correct"
indentation is. So, best to give them a choice.

The new flag is called ObjCBlockIndentWidth and the default is now set
to the same value as IndentWidth for the pre-defined styles.

llvm-svn: 220784

Refactored multiclass through AVX512_maskable

llvm-svn: 220783

llvm-svn: 220782

llvm-svn: 220781

explicitly using the resulting .pcm file. Unlike for an implicit module build,
we don't need nor want to require these flags to match between the module
and its users.

llvm-svn: 220780

[AVX512] Removed special case for cmp instructions in getVectorMaskingNode. Now cmp intrinsics lower as other intrinsics through VSELECT, and then VSELECT tranforms to AND in PerformSELECTCombine.
No functional change.

llvm-svn: 220779

style.

llvm-svn: 220778

[x86] Simplify vector selection if condition value type matches vselect value type and true value is all ones or false value is all zeros.
This transformation worked if selector is produced by SETCC, however SETCC is needed only if we consider to swap operands. So I replaced SETCC check for this case.
Added tests for vselect of <X x i1> values.

llvm-svn: 220777

Summary: Add valueDecl() matcher.

Reviewers: klimek

Subscribers: klimek, cfe-commits

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

llvm-svn: 220776

llvm-svn: 220775

Ffter commit at rev219046 512-bit broadcasts lowering become non-optimal. Most of tests on broadcasting and embedded broadcasting were changed and they doesn’t produce efficient code.

Example below is from commit changes (it’s the first test from test/CodeGen/X86/avx512-vbroadcast.ll):

 define   <16 x i32> @_inreg16xi32(i32 %a) {
 ; CHECK-LABEL: _inreg16xi32:
 ; CHECK:       ## BB#0:
-; CHECK-NEXT:    vpbroadcastd %edi, %zmm0
+; CHECK-NEXT:    vmovd %edi, %xmm0
+; CHECK-NEXT:    vpbroadcastd %xmm0, %ymm0
+; CHECK-NEXT:    vinserti64x4 $1, %ymm0, %zmm0, %zmm0
 ; CHECK-NEXT:    retq
 %b = insertelement <16 x i32> undef, i32 %a, i32 0
 %c = shufflevector <16 x i32> %b, <16 x i32> undef, <16 x i32> zeroinitializer
 ret <16 x i32> %c
}

Here, 256-bit broadcast was generated instead of 512-bit one.

In this patch
1) I added vector-shuffle lowering through broadcasts
2) Removed asserts and branches likes because this is incorrect
-  assert(Subtarget->hasDQI() && "We can only lower v8i64 with AVX-512-DQI");
3) Fixed lowering tests

llvm-svn: 220774

llvm-svn: 220773

llvm-svn: 220772

llvm-svn: 220771

llvm-svn: 220770

[libcxx] Delay evaluation of __make_tuple_types to prevent blowing the max template instantiation depth. Fixes Bug #18345

Summary:
http://llvm.org/bugs/show_bug.cgi?id=18345

Tuple's constructor and assignment operators for "tuple-like" types evaluates __make_tuple_types unnecessarily. In the case of a large array this can blow the template instantiation depth.

Ex:
```
#include <array>
#include <tuple>
#include <memory>
 
typedef std::array<int, 1256> array_t;
typedef std::tuple<array_t> tuple_t;

int main() {
  array_t a;
  tuple_t t(a); // broken
  t = a; // broken

  // make_shared uses tuple behind the scenes. This bug breaks this code.
  std::make_shared<array_t>(a);
}
```

To prevent this from happening we delay the instantiation of `__make_tuple_types` until after we perform the length check. Currently `__make_tuple_types` is instantiated at the same time that the length check .


Test Plan: Two tests have been added. One for the "tuple-like" constructors and another for the "tuple-like" assignment operator. 

Reviewers: mclow.lists, EricWF

Reviewed By: EricWF

Subscribers: K-ballo, cfe-commits

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

llvm-svn: 220769

test/elf/Mips/hilo16-*.test depends on llvm-mc, so we need to
make CMake to build that before running the tests.

llvm-svn: 220768

We don't care about pre-3.12.1 anymore.

llvm-svn: 220767

llvm-svn: 220766

llvm-svn: 220763

PlatformLinux::GetSoftwareBreakpointTrapOpcode.

Patch by Stephane Sezer.
http://reviews.llvm.org/D5923

llvm-svn: 220762

<rdar://problem/18786645> 

llvm-svn: 220761

The option is '--allow-multiple-definition' not '--allow-multiple-definitions'.

llvm-svn: 220760

llvm-svn: 220759

This is a Microsoft calling convention that supports both x86 and x86_64
subtargets. It passes vector and floating point arguments in XMM0-XMM5,
and passes them indirectly once they are consumed.

Homogenous vector aggregates of up to four elements can be passed in
sequential vector registers, but this part is not implemented in LLVM
and will be handled in Clang.

On 32-bit x86, it is similar to fastcall in that it uses ecx:edx as
integer register parameters and is callee cleanup. On x86_64, it
delegates to the normal win64 calling convention.

Reviewers: majnemer

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

llvm-svn: 220745

Benchmarks have shown that it's harmless to the performance there, and having a
unified set of passes between the two cores where possible helps big.LITTLE
deployment.

Patch by Z. Zheng.

llvm-svn: 220744

llvm-svn: 220743