Summary:
As per Duncan's review for D12536, I extracted the sub-byte bit aligned
reading and writing code into lib/Support, and generalized it. Added calls from
BackpatchWord. Also added unittests.

Reviewers: dexonsmith

Subscribers: llvm-commits

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

llvm-svn: 248897

Applied restrictions from OpenCL v2.0 s6.13.11.8
that mainly disallow operations on atomic types (except for taking their address - &).

The patch is taken from SPIR2.0 provisional branch, contributed by Guy Benyei!

llvm-svn: 248896

llvm-svn: 248895

llvm-svn: 248894

This will allow us to reuse this code in a subsequent commit.

llvm-svn: 248893

Reviewed By: reames, hfinkel

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

llvm-svn: 248892

llvm-svn: 248891

llvm-svn: 248890

This test was timing out because the test inferior was forking a child, which was not terminated
correctly. The test contained provisions to terminate this child, but these were no longer
working. The idea was to wake up upon receiving SIGTERM and then kill the child. However, this
was failing because the test first tried to use SIGHUP, which ended up killing the inferior.

Fix: make sure we catch SIGHUP also.
llvm-svn: 248889

This is the clang commit associated with llvm r248887.

This commit changes the interface of the vld[1234], vld[234]lane, and vst[1234],
vst[234]lane ARM neon intrinsics and associates an address space with the
pointer that these intrinsics take. This changes, e.g.,

<2 x i32> @llvm.arm.neon.vld1.v2i32(i8*, i32)

to

<2 x i32> @llvm.arm.neon.vld1.v2i32.p0i8(i8*, i32)

This change ensures that address spaces are fully taken into account in the ARM
target during lowering of interleaved loads and stores.

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

llvm-svn: 248888

This commit changes the interface of the vld[1234], vld[234]lane, and vst[1234],
vst[234]lane ARM neon intrinsics and associates an address space with the
pointer that these intrinsics take. This changes, e.g.,

<2 x i32> @llvm.arm.neon.vld1.v2i32(i8*, i32)

to

<2 x i32> @llvm.arm.neon.vld1.v2i32.p0i8(i8*, i32)

This change ensures that address spaces are fully taken into account in the ARM
target during lowering of interleaved loads and stores.

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

llvm-svn: 248887

llvm-svn: 248886

Reviewed by: rafael

llvm-svn: 248885

When using LLVMConfig.cmake from an installed toolchain in order to build a
loadable pass using add_llvm_loadable_module LLVM_ENABLE_PLUGINS and
LLVM_PLUGIN_EXT must be set. Also make LLVM_DEFINITIONS be set to what it
actually is.

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

llvm-svn: 248884

Currently most of the test files have a separate dwarf and a separate
dsym test with almost identical content (only the build step is
different). With adding dwo symbol file handling to the test suit it
would increase this to a 3-way duplication. The purpose of this change
is to eliminate this redundancy with generating 2 test case (one dwarf
and one dsym) for each test function specified (dwo handling will be
added at a later commit).

Main design goals:
* There should be no boilerplate code in each test file to support the
  multiple debug info in most of the tests (custom scenarios are
  acceptable in special cases) so adding a new test case is easier and
  we can't miss one of the debug info type.
* In case of a test failure, the debug symbols used during the test run
  have to be cleanly visible from the output of dotest.py to make
  debugging easier both from build bot logs and from local test runs
* Each test case should have a unique, fully qualified name so we can
  run exactly 1 test with "-f <test-case>.<test-function>" syntax
* Test output should be grouped based on test files the same way as it
  happens now (displaying dwarf/dsym results separately isn't
  preferable)

Proposed solution (main logic in lldbtest.py, rest of them are test
cases fixed up for the new style):
* Have only 1 test fuction in the test files what will run for all
  debug info separately and this test function should call just
  "self.build(...)" to build an inferior with the right debug info
* When a class is created by python (the class object, not the class
  instance), we will generate a new test method for each debug info
  format in the test class with the name "<test-function>_<debug-info>"
  and remove the original test method. This way unittest2 see multiple
  test methods (1 for each debug info, pretty much as of now) and will
  handle the test selection and the failure reporting correctly (the
  debug info will be visible from the end of the test name)
* Add new annotation @no_debug_info_test to disable the generation of
  multiple tests for each debug info format when the test don't have an
  inferior

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

llvm-svn: 248883

llvm-svn: 248882

  Before we unconditinoally forced all users outside the SCoP to use
  the preloaded value. However, if the SCoP is not executed due to the
  runtime checks, we need to use the original value because it might not
  be invariant in the first place.

llvm-svn: 248881

OpenMP 4.1 allows to use array sections|subscript expressions in 'reduction' clauses. Added sema analysis, updated tests.

llvm-svn: 248880

This makes ScopInfo's scop member available earlier to other methods which will make some planned changes simpler.

No behavioral change intended

llvm-svn: 248879

The XOP shifts just have logical/arithmetic versions and the left/right shifts are controlled by whether the value is positive/negative. Because of this I've added new X86ISD nodes instead of trying to force them to use the existing shift nodes.

Additionally Excavator cores (bdver4) support XOP and AVX2 - meaning that it should use the AVX2 shifts when it can and fall back to XOP in other cases.

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

llvm-svn: 248878

llvm-svn: 248877

llvm-svn: 248876

llvm-svn: 248875

llvm-svn: 248873

llvm-svn: 248872

llvm-svn: 248871

http://reviews.llvm.org/D13145

llvm-svn: 248870

Fix the sample profile format that breaks in test http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/505

http://reviews.llvm.org/D13145

llvm-svn: 248869

So that it is clear that we are incrementing the pointers for sure. NFC.

llvm-svn: 248868

specification) to an error. No compiler other than Clang seems to allow this,
and it doesn't seem like a useful thing to accept as an extension in general.

The current behavior was added for PR5957, where the problem was specifically
related to mismatches of the exception specification on the implicitly-declared
global operator new and delete. To retain that workaround, we downgrade the
error to an ExtWarn when the declaration is of a replaceable global allocation
function.

Now that this is an error, stop trying (and failing) to recover from a missing
computed noexcept specification. That recovery didn't work, and led to crashes
in code like the added testcase.

llvm-svn: 248867

llvm-svn: 248866

Support hierarachical sample profile format.

llvm-svn: 248865

Also added brief comments.

llvm-svn: 248864

llvm-svn: 248863

with a non-reserved operator delete in a new-expression.

llvm-svn: 248862

  As a first step in the direction of assumed invariant loads (loads
  that are not written in some context) we now detect and hoist
  definitively invariant loads. These invariant loads will be preloaded
  in the code generation and used in the optimized version of the SCoP.
  If the load is only conditionally executed the preloaded version will
  also only be executed under the same condition, hence we will never
  access memory that wouldn't have been accessed otherwise. This is also
  the most distinguishing feature to licm.

  As hoisting can make statements empty we will simplify the SCoP and
  remove empty statements that would otherwise cause artifacts in the
  code generation.

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

llvm-svn: 248861

  This reverts commit 07830c18d789ee72812d5b5b9b4f8ce72ebd4207.

  The commit broke at least one test in lnt,
    MultiSource/Benchmarks/Ptrdist/bc/number.c
  was miss compiled and the test produced a wrong result.

  One Polly test case that was added later was adjusted too.

llvm-svn: 248860

llvm-svn: 248859

to prevent setting a huge stride, because DATA_FORMAT has a different
meaning if ADD_TID_ENABLE is set.

This is a candidate for stable llvm 3.7.

Tested-and-Reviewed-by: Christian König <christian.koenig@amd.com>
llvm-svn: 248858

Previously local variable captures just didn't work in 64-bit. Now we
can access local variables more or less correctly.

llvm-svn: 248857