On some of our benchmarks this change shows about 50% compile time improvement without any noticeable performance difference.

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

llvm-svn: 248801

llvm-svn: 248800

llvm-svn: 248799

Currently LLVM_COMPILER_IS_GCC_COMPATIBLE is set as a side-effect of determining
the stdlib to use in HandleLLVMStdlib, which causes problems when attempting to
use AddLLVM from an installed LLVM toolchain, as HandleLLVMStdlib is not used.
Move the setting of this variable into DetermineGCCCompatible and include that
from both AddLLVM and HandleLLVMStdlib.

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

llvm-svn: 248798

Some of the build bots are unhappy about the overload of the global operator new() because it was accidentally marked noexcept instead of noexcept(false). This should correct those bots.

llvm-svn: 248797

If a PHI starts at a non-negative constant, monotonically increases
(only adds of a constant are supported at the moment) and that add
does not wrap, then the PHI is known never to be zero.

llvm-svn: 248796

With RELA that is just wasteful, with REL the relocation gets applied
twice.

llvm-svn: 248795

llvm-svn: 248794

llvm-svn: 248793

Hopefully silencing some built bot warnings. Note, this should be unsigned long instead of unsigned int, but then *other* builds start to fail because of duplicate redefinitions of size_t.

llvm-svn: 248792

Adding a checker (misc-new-delete-overloads) that detects mismatched overloads of operator new and operator delete. Corresponds to the CERT C++ secure coding rule: https://www.securecoding.cert.org/confluence/display/cplusplus/DCL54-CPP.+Overload+allocation+and+deallocation+functions+as+a+pair+in+the+same+scope

llvm-svn: 248791

The test still remains XTIMEOUTed. Will remove that as well if it turns out its passing.

llvm-svn: 248790

On android when debugging an apk we run lldb-server as application user
because the sell user (on non-rooted device) can't attach to an
application. The problem is that "adb pull" will run as a shell user
what can't access to files created by lldb-server because they will be
owned by the application user. This CL changes the oat symbolization
code to run "oatdump --symbolize" to generate an output what is owned
by the shell user.

Differential revision: http://reviews.llvm.org/D13162

llvm-svn: 248788

alignment requirements, for example in the case of vectors.
These requirements are exploited by the code generator by using
move instructions that have similar alignment requirements, e.g.,
movaps on x86.

Although the code generator properly aligns the arguments with
respect to the displacement of the stack pointer it computes,
the displacement itself may cause misalignment. For example if
we have

%3 = load <16 x float>, <16 x float>* %1, align 64
call void @bar(<16 x float> %3, i32 0)

the x86 back-end emits:

movaps  32(%ecx), %xmm2
movaps  (%ecx), %xmm0
movaps  16(%ecx), %xmm1
movaps  48(%ecx), %xmm3
subl    $20, %esp       <-- if %esp was 16-byte aligned before this instruction, it no longer will be afterwards 
movaps  %xmm3, (%esp)   <-- movaps requires 16-byte alignment, while %esp is not aligned as such.
movl    $0, 16(%esp)
calll   __bar

To solve this, we need to make sure that the computed value with which
the stack pointer is chang...

Summary: create a check that replaces 'std::unique_ptr<type>(new type(args...))' with 'std::make_unique<type>(args...)'. It was on the list of "Ideas for new Tools". It needs to be tested more carefully, but first I wanted to know if you think it is worth the effort.

Reviewers: klimek

Subscribers: cfe-commits

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

llvm-svn: 248785

Currently SimplifyDemandedVectorElts can only peek through bitcasts if the vectors have the same number of elements.

This patch fixes and enables some existing (disabled) code to support bitcasting to vectors with more/fewer elements. It currently only accepts cases when vectors alias cleanly (i.e. number of elements are an exact multiple of the other vector).

This was added to improve the demanded vector elements support for SSE vector shifts which require the __m128i (<2 x i64>) argument type to be bitcast to the vector type for the builtin shift. I've added extra tests for various additional bitcasts.

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

llvm-svn: 248784

llvm-svn: 248783

Recognize the main module header as well as different #include categories.
This should now mimic the behavior of llvm/utils/sort_includes.py as
well as clang-tools-extra/clang-tidy/llvm/IncludeOrderCheck.cpp very
closely.

llvm-svn: 248782

Every once in a while we see code that accesses memory with different types,
e.g. to perform operations on a piece of memory using type 'float', but to copy
data to this memory using type 'int'. Modeled in C, such codes look like:

    void foo(float A[], float B[]) {
      for (long i = 0; i < 100; i++)
        *(int *)(&A[i]) = *(int *)(&B[i]);
      for (long i = 0; i < 100; i++)
        A[i] += 10;
    }

We already used the correct types during normal operations, but fall back to our
detected type as soon as we import changed memory access functions. For these
memory accesses we may generate invalid IR due to a mismatch between the element
type of the array we detect and the actual type used in the memory access.  To
address this issue, we always cast the newly created address of a memory access
back to the type of the memory access where the address will be used.

llvm-svn: 248781

This is a port from the AMD builtin library.

llvm-svn: 248780

Besides a trivial MIPS support the patch introduces new TargetInfo class
member getDefaultEntry() to override default name of the entry symbol.
MIPS uses __start for that.

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

llvm-svn: 248779

llvm-svn: 248778

Summary: This patch adds block frequency analysis to LoopUnswitch pass to recognize hot/cold regions. For cold regions the pass only performs trivial unswitches since they do not increase code size, and for hot regions everything works as before. This helps to minimize code growth in cold regions and be more aggressive in hot regions. Currently the default cold regions are blocks with frequencies below 20% of function entry frequency, and it can be adjusted via -loop-unswitch-cold-block-frequency flag. The entire feature is controlled via -loop-unswitch-with-block-frequency flag and it is off by default.

Reviewers: broune, silvas, dnovillo, reames

Subscribers: davidxl, llvm-commits

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

llvm-svn: 248777

llvm-svn: 248776

Sema thinks the cast is a no-op, as it does when (e.g.) the
only thing that changes is an alignment attribute.

Fixed PR24944.

llvm-svn: 248775

llvm-svn: 248774

llvm-svn: 248773

Description.
If the simd clause is specified, the ordered regions encountered by any thread will use only a single SIMD lane to execute the ordered regions in the order of the loop iterations.
Restrictions.
An ordered construct with the simd clause is the only OpenMP construct that can appear in the simd region.

An ordered directive with ‘simd’ clause is generated as an outlined function and corresponding function call to prevent this part of code from vectorization later in backend.

llvm-svn: 248772

It is described in LLVMBuild.txt.

llvm-svn: 248771

Place new and update dbg.declare calls immediately after the
corresponding alloca.

Current code in replaceDbgDeclareForAlloca puts the new dbg.declare
at the end of the basic block. LLVM codegen has problems emitting
debug info in a situation when dbg.declare appears after all uses of
the variable. This usually kinda works for inlining and ASan (two
users of this function) but not for SafeStack (see the pending change
in http://reviews.llvm.org/D13178).

llvm-svn: 248769

llvm-svn: 248768

There are always more physical registers and register units so the
previous behaviour was correct but we can do with less memory.

llvm-svn: 248767

Remove unnecessary default dtor. The base dtor is already virtual and the derived dtor adds nothing.

llvm-svn: 248765

This is a bit of an awkward API and I'm not sure what the right solution
is. Having a publicly copy constructible base class makes it easy to
accidentally slice derived objects in a number of contexts.

llvm-svn: 248764

Previously we were hijacking the old LandingPadInfo data structures to
communicate our state numbers. Now we don't need that anymore.

llvm-svn: 248763

Thanks to echristo for noticing!

llvm-svn: 248762

LookupResult should not be copyable, it's not readily copyable and can
only be copied when it's in specific states (in a query state, without
any results, basically). Instead, just extract the /query/ state and
pass that across the copy boundary, then build a new LookupResult on the
other side.

I wonder if a better API (one in which the query state is separate from
the result state - essentialyl making QueryState a first class part of
the Lookup API - pass a QueryState, get a LookupResult, rather than
mutating the LookupResult in place (LookupResult could contain a
QueryState if it's particularly helpful to be able to observe the query
parameters while also examining the result)) might be a good idea here.

Future patches will probably make LookupResult actually non-copyable
(transition the CXXBasePaths to unique_ptr, for example) and hopefully
we'll enable -Wdeprecated in LLVM soon to avoid issues like this.

llvm-svn: 248761

Add an explicitly defaulted copy ctor (and FIXME) to Command since its copy ctor is currently used (and actually slices derived objects... ) in some diagnostics handling.

Justin mentioned he'd look into this.

llvm-svn: 248760

And also remove an unused variable that's now diagnosed by
-Wunused-variable since the dtor is now trivial.

llvm-svn: 248759

We don't want to filter out the builtins that are present in libSystem like we do for the normal builtins because kexts can't link libSystem, but we should filter out all the builtins that are generally not supported on the OS and architecture.

llvm-svn: 248756