llvm-svn: 204486

The `llvm-profdata show` command summarizes a profdata file's contents
in a human readable format.

llvm-svn: 204485

Use new(allocator_for_flags) instead of allocator_for_flags.Allocate()
Fix the description output format a bit.

llvm-svn: 204484

The production of the .eh symbols is done from MC now and we already have tests
for it.

llvm-svn: 204483

This introduces the ProfileData library and updates llvm-profdata to
use this library for reading profiles. InstrProfReader is an abstract
base class that will be subclassed for both the raw instrprof data
from compiler-rt and the efficient instrprof format that will be used
for PGO.

llvm-svn: 204482

llvm-svn: 204481

Summary:
VECTOR_SHUFFLE concatenates the vectors in an vectorwise fashion.
  <0b00, 0b01> + <0b10, 0b11> -> <0b00, 0b01, 0b10, 0b11>
VSHF concatenates the vectors in a bitwise fashion:
  <0b00, 0b01> + <0b10, 0b11> ->
  0b0100       + 0b1110       -> 0b01001110
                                 <0b10, 0b11, 0b00, 0b01>
We must therefore swap the operands to get the correct result.

The test case that discovered the issue was MultiSource/Benchmarks/nbench.

Reviewers: matheusalmeida

Reviewed By: matheusalmeida

Differential Revision: http://llvm-reviews.chandlerc.com/D3142

llvm-svn: 204480

llvm-svn: 204479

Patch by: Jeroen Ketema

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 204478

Patch by: Jeroen Ketema

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 204477

llvm-svn: 204476

llvm-svn: 204475

The SReg_(32|64) register classes contain special registers in addition
to the numbered SGPRs.  This can lead to machine verifier errors when
these register classes are used as sub-registers for SReg_128, since
SReg_128 only uses the numbered SGPRs.

Replacing SReg_(32|64) with SGPR_(32|64) fixes this problem, since
the SGPR_(32|64) register classes contain only numbered SGPRs.

Tests cases for this are comming in a later commit.

llvm-svn: 204474

CodeGen treats allocas outside the entry block as dynamically sized
stack objects.

llvm-svn: 204473

llvm-svn: 204472

Fixing code that doesn't compile in MSVC 2012 (but does in MSVC 2013) from r204417 and related commits.

llvm-svn: 204471

For complex examples it may happen that we do not compute dependences. In this
case we do not want to crash, but just not detect parallel loops.

llvm-svn: 204470

The release_capability, release_shared_capability and release_generic_capability functions are now functionally distinct for capability analysis. The unlock_function attribute maps directly to release_generic_capability.

llvm-svn: 204469

llvm-svn: 204468

This unbreaks polly-formatting-tests and we can make a decision for
LLVM style independently.

llvm-svn: 204467

llvm-svn: 204466

Simplify test/CodeGenCXX/microsoft-abi-vtables-virtual-inheritance-vtordisps.cpp by forcing VFTableBuilder invocation with virtual function calls

Previously the vftables were built at the end of the TU in a reverse-to-random order

llvm-svn: 204465

Simplify test/CodeGenCXX/microsoft-abi-vtables-multiple-nonvirtual-inheritance.cpp by forcing VFTableBuilder invocation with virtual function calls

Previously the vftables were built at the end of the TU in a reverse-to-random order

llvm-svn: 204464

from (external) compiler-rt build tree into LLVM/Clang build tree in
LLVM_BUILD_EXTERNAL_COMPILER_RT mode.

For instance, running
  make asan -j12
in LLVM/Clang build tree will now build Clang, use it to configure
compiler-rt build tree, and invoke "make asan -j12" there. ASan runtime will
be built in the proper location, where Clang driver expects to find it.

Running
  make check-asan
will build Clang, use it to configure compiler-rt build tree, build everything
there, and then run "make check-asan" in compiler-rt build tree using just-built
Clang and ASan runtime.

llvm-svn: 204463

llvm-svn: 204462

llvm-svn: 204461

They very rarely aid readability.

Formatting:
  void f() {

    if (a) {

      f();

    }

  }

Now leads to:
  void f() {
    if (a) {
      f();
    }
  }

llvm-svn: 204460

Previous check relied on -DLLDB_DISABLE_PYTHON which was not valid as
it is defined in the top level LLDB Makefile which is included after the check.
If this check is moved after the inclusion of top level Makefile then 
BUILT_SOURCES is not properly handled. So I am using the scheme present
in the Host/Makefile.

llvm-svn: 204459

Before:
  vector<int> x{1, 2, 3, 4, };

After:
  vector<int> x{
      1, 2, 3, 4,
  };

This fixes llvm.org/PR18519.

llvm-svn: 204458

llvm-svn: 204457

Formatting:
  SomeFunction(a,
            b, // comment
            c);

Before:
  SomeFunction(a, b, // comment
               c);

After:
  SomeFunction(a,
               b, // comment
               c);

llvm-svn: 204456

Simplify test/CodeGenCXX/microsoft-abi-vtables-single-inheritance.cpp by forcing VFTableBuilder invocation with virtual function calls

Previously the vftables were built at the end of the TU in a reverse-to-random order

llvm-svn: 204455

llvm-svn: 204454

llvm-svn: 204453

...instead of a separate Requires for each one.  This style was already
used in some places and seems more compact.

No behavioral change intended.

llvm-svn: 204452

These complement the older float<->signed instructions.

llvm-svn: 204451

We should be using the llvm namespace and not an anonymous namespace
in a header file.

llvm-svn: 204450

PATH_MAX is defined if it is not already defined. A duplicate
definition is removed. The declaration of struct timespec is moved
outside #ifdef _MSC_VER to make it available for mingw.

llvm-svn: 204449

Using __msan_unpoison() on null-terminated strings is awkward because
strlen() can't be called on a poisoned string. This case warrants a special
interface function.

llvm-svn: 204448

It does not seem to add a lot of value, as it leaves unclear which parts are
mature and whichs not. Adding this informatin also does not make sense, as it
changes rapidly.

llvm-svn: 204447