This commit starts with a "git mv ARM64 AArch64" and continues out
from there, renaming the C++ classes, intrinsics, and other
target-local objects for consistency.

"ARM64" test directories are also moved, and tests that began their
life in ARM64 use an arm64 triple, those from AArch64 use an aarch64
triple. Both should be equivalent though.

This finishes the AArch64 merge, and everyone should feel free to
continue committing as normal now.

llvm-svn: 209577

I'm doing this in two phases for a better "git blame" record. This
commit removes the previous AArch64 backend and redirects all
functionality to ARM64. It also deduplicates test-lines and removes
orphaned AArch64 tests.

The next step will be "git mv ARM64 AArch64" and rewire most of the
tests.

Hopefully LLVM is still functional, though it would be even better if
no-one ever had to care because the rename happens straight
afterwards.

llvm-svn: 209576

llvm-svn: 209575

Support a 'keep-going' mode for the ScopDetection. In this mode, we just keep
on detecting, even if we encounter an error.

This is useful for diagnosing SCoP candidates. Sometimes you want all the
errors. Invalid SCoPs will still be refused in the end, we just refuse to
abort on the first error.

llvm-svn: 209574

Use the new ScopDetectionDiagnostics to implement
the same functionality.

llvm-svn: 209573

This stores all RejectReasons created for one region
in a RejectLog inside the DetectionContext. For now
this only keeps track of the last error.

A separate patch will enable the tracking of all errors.
This patch itself does no harm (yet).

llvm-svn: 209572

We don't want the Statistic variables in every module that
includes the diagnostics.

llvm-svn: 209571

It didn't match on non-English version of Windows.

llvm-svn: 209570

On win32, %s is expanded to X:\path\to\test\line-filter.cpp. It was incompatible to yaml.
Although "%/s" could be available in Lit, ClangTidyDiagnosticConsumer::passesLineFilter() is unaware of comparision between '/' and '\\'.

llvm-svn: 209569

sext{C1,+,C2} --> sext(C1) + sext{0,+,C2} transformation in Scalar
Evolution.

That helps SLP-vectorizer to recognize consecutive loads/stores.

<rdar://problem/14860614>

llvm-svn: 209568

instead of before. The wrong order had no effect since Deallocate() 
does nothing right now, but we may replace allocator in the future.

llvm-svn: 209567

After the load/store refactoring, we were sometimes trying to feed a
GPR64 into a 32-bit register offset operand. This failed in
copyPhysReg.

llvm-svn: 209566

I forgot to fix this one in r209145. We use these flags on dllimport tests
to make sure we emit code for available_externaly functions and don't inline
the IR.

llvm-svn: 209564

trying to populate the list of trap handler names at
the same time don't conflict with one another.
<rdar://problem/17011969> 

llvm-svn: 209563

Removed a "done" TODO comment.

Moved some helper methods to the top of the unit test.

Removed some commented out code I was considering implementing
before I came up with a better overall approach.

llvm-svn: 209561

Added test to check that each thread reported by $q{f,s}ThreadInfo
can be switched to by $Hg, verified by a follow-up $qC.

Modified test exe to accept "thread:new" to create a new thread 
that runs and sleeps for 5 seconds.

@llgs_test/@debugserver_test now buffer output.
   
llgs and debugserver gdbremote protocol tests now collect $O notification
output into the context returned from expect_lldb_gdbserver_replay.
context["O_count"] is an integer indicating the number of $O packets
collected during the replay, and context["O_content"] contains the
accumulated hex-decoded text output by the inferior (stdout and stderr).

Modified the $O check test to check the accumulated output rather than
a direct $O packet.

llvm-svn: 209560

This is a test case for r209489.

llvm-svn: 209559

llvm-svn: 209558

rather than saving and restoring it.

llvm-svn: 209557

llvm-svn: 209556

Initializers of global data that can appear multiple TUs (static data
members of class templates or __declspec(selectany) data) are now in a
comdat group keyed on the global variable being initialized.  On
non-Windows platforms, this is a code size and startup time
optimization.  On Windows, this is necessary for ABI compatibility with
MSVC.

Fixes PR16959.

Reviewers: rsmith

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

llvm-svn: 209555

In an effort to fix inlined debug info in situations where the out of
line definition of a function preceeds any inlined usage, the order in
which some attributes are added to subprogram DIEs may change. (in
essence, definition-necessary attributes like DW_AT_low_pc/high_pc will
be added immediately, but the names, types, and other features will be
delayed to module end where they may either be added to the subprogram
DIE or instead reference an abstract definition for those values)

These tests can be generalized to be resilient to this change. 5 or so
tests actually have to be incompatibly changed to cope with this
reordering and will go along with the change that affects the order.

llvm-svn: 209554

It's an unnecessary detail for this test and just gets in the way when
making unrelated changes to the output in this test.

llvm-svn: 209553

gets explicitly specialized, don't reuse the previous class template
specialization declaration as a new declaration. The benefit here is fairly
marginal, it harms source fidelity, and this is horrible to model if the
specialization was imported from another module (without this change, it
asserts or worse).

llvm-svn: 209552

llvm-svn: 209551

llvm-svn: 209550

The previous code that was supposed to handle this didn't work
since parsing of inline method definitions is delayed to the end
of the outer class definition. Thus, when HandleTagDeclDefinition()
got called for the inner class, the inline functions in that class
had not been parsed yet.

Richard suggested that the way to do this is by handling inline
method definitions through a new ASTConsumer callback.

I really wanted to call ASTContext::DeclMustBeEmitted() instead of
checking for attributes, but doing that causes us to compute linkage,
and then we fail with "error: unsupported: typedef changes linkage
of anonymous type, but linkage was already computed" on tests like
this: (from SemaCXX/undefined-internal.cpp) :-/

  namespace test7 {
    typedef struct {
      void bar();
      void foo() { bar(); }
    } A;
  }

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

llvm-svn: 209549

No functionality change.

llvm-svn: 209548

DebugInfo: Put concrete definitions referencing abstract definitions in the same scope as the abstract definition.

This seems like a simple cleanup/improved consistency, but also helps
lay the foundation to fix the bug mentioned in the test case: concrete
definitions preceeding any inlined usage aren't properly split into
concrete + abstract (because they're not known to need it until it's too
late).

Once we start deferring this choice until later, we won't have the
choice to put concrete definitions for inlined subroutines in a
different scope from concrete definitions for non-inlined subroutines
(since we won't know at time-of-construction which one it'll be). This
change brings those two cases into alignment ahead of that future
chaneg/fix.

llvm-svn: 209547

It's true the MSVC doesn't warn about dllimport when applied to e.g. a typedef,
but that applies to dllexport too. I'd like us to be consistent, and I think
the right thing to do is to warn.

The original test that came with implementing the old behaviour doesn't provide
a good motivation, and it said it was checking that we're not repoting an *error*,
which is still true since this is just a warning.

There are plenty of tests e.g. in Sema/dllimport.c to check that we do warn
about dllimport on non functions or variables.

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

llvm-svn: 209546

This is a follow-up to r209358: PR19799: Indvars miscompile due to an
incorrect max backedge taken count from SCEV.

That fix was incomplete as pointed out by Arnold and Michael Z. The
code was also too confusing. It needed a careful rewrite with more
unit tests. This version will also happen to optimize more cases.

<rdar://17005101> PR19799: Indvars miscompile...

llvm-svn: 209545

This reverts part of commit r209538.

llvm-svn: 209544

This matches both what we do for the non-thread case and what gcc does.

With this patch clang would match gcc's behaviour in

static __thread int a = 42;
extern __thread int b __attribute__((alias("a")));
int *f(void) { return &a; }
int *g(void) { return &b; }

if not for pr19843. Manually writing the IL does produce the same access modes.

It is also a step in the direction of fixing pr19844.

llvm-svn: 209543

llvm-svn: 209542

llvm-svn: 209541

llvm-svn: 209540

llvm-svn: 209539

llvm-svn: 209538

Fixed a TODO in r207783.

Add the extracted constant offset using GEP instead of ugly
ptrtoint+add+inttoptr. Using GEP simplifies future optimizations and makes IR
easier to understand. 

Updated all affected tests, and added a new test in split-gep.ll to cover a
corner case where emitting uglygep is necessary.

llvm-svn: 209537

We do all of our address arithmetic in 64-bit, and operations involving
logically negative 32-bit offsets (actually represented as unsigned 64 bit ints)
often overflow into higher bits. The overflow check could be preserved by
casting to uint32 at the callsite for applyRelocationValue, but this would
eliminate the value of the check.

The right way to handle overflow in relocations is to make relocation processing
target specific, and compute the values for RelocationEntry objects in the
appropriate types (32-bit for 32-bit targets, 64-bit for 64-bit targets). This
is coming as part of the cleanup I'm working on.

This fixes another i386 regression test.

<rdar://problem/16889891>

llvm-svn: 209536