llvm-svn: 228696

llvm-svn: 228695

Summary: Add translationUnitDecl matcher.

Reviewers: alexfh

Subscribers: klimek, cfe-commits

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

llvm-svn: 228694

llvm-svn: 228693

llvm-svn: 228692

On Windows, we now use RaiseException to generate the kind of trap we require (one which calls our vectored exception handler), and fall back to using a volatile write to simulate a trap elsewhere.

llvm-svn: 228691

Patch by Vinicius Tinti.

llvm-svn: 228690

llvm-svn: 228689

Added most of the missing vector folding patterns for AVX2 (as well as fixing the vpermpd and verpmq patterns)

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

llvm-svn: 228688

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

llvm-svn: 228687

Background: When handling underlying objects for a store, the vector
of previous mem uses, mapped to the same Value, is afterwards cleared
(regardless of ThisMayAlias). This means that during handling of the
next store using the same Value, adjustChainDeps() must be called,
otherwise a dependency might be missed.

For example, three spill/reload (NonAliasing) memory accesses using
the same Value 'a', with different offsets:

    SU(2): store  @a
    SU(1): store  @a, Offset:1
    SU(0): load   @a

In this case we have:

* SU(1) does not need a dep against SU(0). Therefore,SU(0) ends up in
  RejectMemNodes and is removed from the mem-uses list (AliasMemUses
  or NonAliasMemUses), as this list is cleared.

* SU(2) needs a dep against SU(0). Therefore, SU(2) must check
  RejectMemNodes by calling adjustChainDeps().

Previously, for store SUs, adjustChainDeps() was only called if
MayAlias was true, missing the S(2) to S(0) dependency in the case
above. The fix is to always call adjustChainDeps(), regardless of
MayAlias, since this applies both for AliasMemUses and
NonAliasMemUses.

No testcase found for any in-tree target.

llvm-svn: 228686

This patch adds the complete AMD Bulldozer XOP instruction set to the memory folding pattern tables for stack folding, etc.

Note: Many of the XOP instructions have multiple table entries as it can fold loads from different sources.

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

llvm-svn: 228685

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

llvm-svn: 228683

This patch teaches X86FastISel how to select AVX instructions for scalar
float/double convert operations.

Before this patch, X86FastISel always selected legacy SSE instructions
for FPExt (from float to double) and FPTrunc (from double to float).

For example:
\code
  define double @foo(float %f) {
    %conv = fpext float %f to double
    ret double %conv
  }
\end code

Before (with -mattr=+avx -fast-isel) X86FastIsel selected a CVTSS2SDrr which is
legacy SSE:
  cvtss2sd %xmm0, %xmm0

With this patch, X86FastIsel selects a VCVTSS2SDrr instead:
  vcvtss2sd %xmm0, %xmm0, %xmm0

Added test fast-isel-fptrunc-fpext.ll to check both the register-register and
the register-memory float/double conversion variants.

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

llvm-svn: 228682

Summary:
Add thread-id field in *stopped notification (MI) + tests

All tests pass on OS X

Reviewers: zturner, clayborg, abidh

Reviewed By: clayborg

Subscribers: lldb-commits, zturner, clayborg, abidh

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

llvm-svn: 228681

When calling ARM code from Thumb and vice versa,
a veneer that switches instruction set should be generated.
Added veneer generation for ARM_JUMP24 ARM_THM_JUMP24 instructions.

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

llvm-svn: 228680

Algorithms like remove() does not actually remove any element from the
container but returns an iterator to the first redundant element at the end
of the container. These redundant elements must be removed using the
erase() method. This check warns when not all of the elements will be
removed due to using an inappropriate overload.

Reviewer: alexfh

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

llvm-svn: 228679

The parameter definition of this API is const volatile __int64*, but it is not defined correctly in clang. Move the 'CD' to the correct location.

Bug tracked here: http://llvm.org/bugs/show_bug.cgi?id=21004

Patch by Daniel Jump!

llvm-svn: 228678

This commit isn't using the correct context, and is transfoming calls
that are operands to loads rather than calls that are operands to an
icmp feeding into an assume. I've replied on the original review thread
with a very reduced test case and some thoughts on how to rework this.

llvm-svn: 228677

std::strings) rather than StringRefs in JITSymbol get-address lambda.

Capturing a StringRef by-value is still effectively capturing a reference, which
is no good here because the referenced string may be gone by the time the lambda
is being evaluated the original value may be gone. Make sure to capture a
std::string instead.

No test case: This bug doesn't manifest under OrcMCJITReplacement, since it
keeps IR modules (from which the StringRefs are sourced) alive permanently.

llvm-svn: 228676

llvm-svn: 228675

llvm-svn: 228674

Somehow a check for aarch64 was added to the Darwin toolchain's
isKernelStatic function as part of the initial commit for Apple's
arm64 target (r205100). That check was not in any of Apple's internal
code and no one here knows where it came from. It has been harmless
because "-static" does not change much, if anything, for arm64 iOS code,
but it makes no sense to keep this check.

llvm-svn: 228673

[X86] Preserve mem refs on newly created 'Store' node instead of 'Load' node when handling store unfolding.

Bug spotted by Steve King.

I have no idea how to test this.

llvm-svn: 228672

llvm-svn: 228671

Since header files are not compilation units, CMake does not require
you to specify them in the CMakeLists.txt file.  As a result, unless a
header file is explicitly added, CMake won't know about it, and when
generating IDE-based projects, CMake won't put the header files into
the IDE project.  LLVM currently tries to deal with this in two ways:

  1) It looks for all .h files that are in the project directory, and
     adds those.
  2) llvm_add_library() understands the ADDITIONAL_HEADERS argument,
     which allows one to list an arbitrary list of headers.

This patch takes things one step further.  It adds the ability for
llvm_add_library() to take an ADDITIONAL_HEADER_DIRS argument, which
will specify a list of folders which CMake will glob for header files.
Furthermore, it will glob not only for .h files, but also for .inc
files.

Included in this CL is an update to one of the existing users of
ADDITIONAL_HEADERS to use this new argument instead, to serve as an
illustration of how this cleans up the CMake.

The big advantage of this new approach is that until now, there was no
way for the IDE projects to locate the header files that are in the
include tree.  In other words, if you are in, for example,
lib/DebugInfo/DWARF, the corresponding includes for this project will
be located under include/llvm/DebugInfo/DWARF.  Now, in the
CMakeLists.txt for lib/DebugInfo/DWARF, you can simply write:

  ADDITIONAL_HEADER_DIRS
  ../../include/llvm/DebugInfo/DWARF

as an argument to llvm_add_library(), and all header files will get
added to the IDE project.

Differential Revision: http://reviews.llvm.org/D7460
Reviewed By: Chris Bieneman

llvm-svn: 228670

This allows all CMake projects, as well as C++ code, to detect if
and when DIA SDK is available for use so that we can enable the
DIA-based PDB reader implementation.

Differential Revision: http://reviews.llvm.org/D7457
Reviewed By: Chandler Carruth

llvm-svn: 228669

gcc still defaults to C89 which does not support BCPL style comments.  This
splits up the sources list in CMakeLists and selectively adds compile flags for
using C99 which avoids a number of warnings in -Wpedantic mode.  NFC.

llvm-svn: 228665

Clean up some stray semicolons found by GCC 4.9 -Wpedantic.  NFC.

llvm-svn: 228664

The unified register management interfaces had multiple naked macros for
conditional logic.  This cleans them up to use the defined() form, avoiding
-Wundef warnings.  NFC.

llvm-svn: 228663

Clean up the format specifiers for pedantic compilation with gcc 4.9 on Linux.
NFC.

llvm-svn: 228662

already have, check whether the name from the module is actually newer than the
existing declaration. If it isn't, we might (say) replace a visible declaration
with an injected friend, and thus make it invisible (or lose a default argument
or an array bound).

llvm-svn: 228661

llvm-svn: 228660

llvm-svn: 228659

Add a "launch with globber" mode that lets you launch a process after having globbed the command line arguments via argdumper instead of routing via /bin/sh

llvm-svn: 228658

llvm-svn: 228657

nodes when folding bitcasts of constants.

We can't fold things and then check after-the-fact whether it was legal.
Once we have formed the DAG node, arbitrary other nodes may have been
collapsed to it. There is no easy way to go back. Instead, we need to
test for the specific folding cases we're interested in and ensure those
are legal first.

This could in theory make this less powerful for bitcasting from an
integer to some vector type, but AFAICT, that can't actually happen in
the SDAG so its fine. Now, we *only* whitelist specific int->fp and
fp->int bitcasts for post-legalization folding. I've added the test case
from the PR.

(Also as a note, this does not appear to be in 3.6, no backport needed)

llvm-svn: 228656

llvm-svn: 228655

llvm-svn: 228654

Summary:
The CMake configuration is explicitely looking for Debug build, all the
other variant disable assertions.

Subscribers: llvm-commits

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 228653