Visual studio can't handle the asm extension in the KMP_USE_TSX code sections.

llvm-svn: 255514

llvm-svn: 255513

Also fix bug in vector legalization for bitreverse.

llvm-svn: 255512

llvm-svn: 255511

llvm-svn: 255510

Reviewers: t.p.northover, jmolloy, mcrosier

Subscribers: aemerson, rengolin, llvm-commits

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

llvm-svn: 255509

If the original MMO had an offset, it was dropped.
Also use the correct alignment after adding the new offset.

llvm-svn: 255508

llvm-svn: 255507

This change should not change the behavior of Polly today, but it allows
external constants to be remapped e.g. when targetting multiple LLVM modules.

llvm-svn: 255506

llvm-svn: 255505

This is a fix for PR25543:
https://llvm.org/bugs/show_bug.cgi?id=25543

The idea is to take the existing fold of:
bitcast ( trunc ( lshr ( bitcast X))) --> extractelement (bitcast X)
( http://reviews.llvm.org/rL112232 )

And break it into less specific transforms so we'll catch more cases such as
the example in the bug report:
bitcast ( trunc ( lshr ( bitcast X))) -->
bitcast ( extractelement (bitcast X)) -->
extractelement (bitcast X)

Enabling patches for this change:
http://reviews.llvm.org/rL255399 (combine bitcasts)
http://reviews.llvm.org/rL255433 (canonicalize extractelement(bitcast X))

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

llvm-svn: 255504

This reverts commit r255471.

Johannes raised in the post-commit review of r255471 the concern that PHI
writes in non-affine regions with two exiting blocks are not really MUST_WRITE,
but we just know that at least one out of the set of all possible PHI writes
will be executed. Modeling all PHI nodes as MUST_WRITEs is probably save, but
adding the needed documentation for such a special case is probably not worth
the effort. Michael will be proposing a new patch that ensures only a single
PHI_WRITE is created for non-affine regions, which - besides other benefits -
should also allow us to use a single well-defined MUST_WRITE for such PHI
writes.

(This is not a full revert, but the condition and documentation have been
slightly extended)

llvm-svn: 255503

- Removed support for hexagonv3 and earlier.
- Added handling of hexagonv55 and hexagonv60.
- Added handling of target features (hvx, hvx-double).
- Updated paths to reflect current directory layout.

llvm-svn: 255502

llvm-svn: 255501

Check that memory accesses in non-affine regions that are always executed are
MUST_WRITE.

llvm-svn: 255500

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

llvm-svn: 255499

llvm-svn: 255498

llvm-svn: 255497

Now with variadic support for msan on aarch6 there is no need for
XFAIL signal_stress_test anymore.  Also to garantee aligned stores
for the FP/SIMD arguments enforce the '__msan_va_arg_tls' alignment
to sizeof the SIMD register (16).

llvm-svn: 255496

This patch add support for variadic argument for AArch64.  All the MSAN
unit tests are not passing as well the signal_stress_test (currently
set as XFAIl for aarch64).

llvm-svn: 255495

We're using the dispatch group itself to synchronize (to call Release() and Acquire() on it), but in dispatch group notifications, the group can already be disposed/deallocated. This causes a later assertion failure at `DCHECK_EQ(*meta, 0);` in `MetaMap::AllocBlock` when the same memory is reused (note that the failure only happens in debug builds).

Fixing this by retaining the group and releasing it in the notification. Adding a stress test case that reproduces this.

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

llvm-svn: 255494

Summary:
Previously the add_test_categories would simply overwrite the current set of categories for a
method. This change makes the decorator truly "add" categories, by extending the current set of
categories instead of replacing it.

To do this, I have:
- replaced the getCategories() property on a method (which was itself a method), with a simple
  list property "categories". This makes add_test_categories easier to implement, and test
  categories isn't something which should change between calls anyway.
- rewritten the getCategoriesForTest function to merge method categories with the categories of
  the test case. Previously, it would just use the method categories if they were present. I have
  also greatly simplified this method. Originally, it would use a lot of introspection to enable
  it being called on various types of objects. Based on my tests, it was only ever being called
  on a test case. The new function uses much less introspection then the preivous one, so we
  should easily catch any stray uses, if there are any, as they will generate exceptions now.

Reviewers: zturner, tfiala, tberghammer

Subscribers: lldb-commits

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

llvm-svn: 255493

one of the tests seems to (occasionally) fail with clang as well.

llvm-svn: 255492

The safestack overflow.c test is currently failing on an aarch64
buildbot with a segfault, but it is currently passing on other
configuration.

This patch silent the issue for now on aarch64 by setting to all
supported architectures the 'stable-runtime' configure and set
the test to requires it.

llvm-svn: 255491

llvm-svn: 255490

In conditional store merging, we were creating PHIs when we didn't
need to. If the value to be predicated isn't defined in the block
we're predicating, then it doesn't need a PHI at all (because we only
deal with triangles and diamonds, any value not in the predicated BB
must dominate the predicated BB).

This fixes a large code size increase in some benchmarks in a popular embedded benchmark suite.

llvm-svn: 255489

[LLDB][MIPS] Mark TestConcurrentEvents.py expected failure, as MIPS atomic sequences are yet to be supported in LLDB

Reviewers: jaydeep.
Subscribers: lldb-commits.
Differential Revision: http://reviews.llvm.org/D15488

llvm-svn: 255488

Debug info for statement under 'atomic' construct must point exactly to that statement, not the directive itself.

llvm-svn: 255487

Revision 251405 added AlwaysBreak to support Google's JavaScript style. This
changeset complete existing AlignsAfterOpenBracket tests to exercise
AlwaysBreak for C++.

I thought this would be worthwhile.  With this option we can support request
from http://lists.llvm.org/pipermail/cfe-dev/2015-May/042942.html, that had
been requested a few times. This also partially solve related Bug 23422 and is
probably sufficient for most people.

  AlignAfterOpenBracket = FormatStyle::BAS_AlwaysBreak;
  BinPackArguments = false;
  BinPackParameters = false;

With these setting we obtain this formatting:

  void fooWithAVeryLongParamList(
      int firstParameter,
      int secondParameter
      int lastParameter)
  {
      object.alsoThisDoenstFitSoIBreakImmidiatly(
          firstParameter,
          secondParameter,
          lastParameter);
  }

Patch by Jean-Philippe Dufraigne, thank you.

llvm-svn: 255486

llvm-svn: 255485

Brought up in codereviews:
http://reviews.llvm.org/D15445
http://reviews.llvm.org/D15485

llvm-svn: 255484

llvm-svn: 255483

It's O(N^2) because it does a simple walk through the existing types to
find duplicates, but that will be fixed in a follow-up commit to use a
mapping data structure of some kind.

llvm-svn: 255482

llvm-svn: 255481

llvm-svn: 255480

clang-tools-extra/test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index*.cpp: Don't assume size_t were unsigned int.

llvm-svn: 255475

Adapt the method names to the new scheme introduced in r255467.

llvm-svn: 255474

Before this commit, only the region's entry block was assumed to always
execute in a non-affine subregion. We replace this by a test whether it
dominates the exit block (this necessarily includes the entry block)
which should be more accurate.

llvm-svn: 255473

This harmonizes DT with the other analyses in ScopInfo and makes it
available for use in its methods.

llvm-svn: 255472

LLVM's IR guarantees that a value definition occurs before any use, and
also the value of a PHI must be one of the incoming values, "written"
in one of the incoming blocks. Hence, such writes are never conditional
in the context of a non-affine subregion.

llvm-svn: 255471