| Commit message (Collapse) | Author | Age | Files | Lines | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This isn't a format we'll want to write out in practice, but moving it
to the writer library simplifies llvm-profdata and isolates it from
further changes to the format.
This also allows us to update the tests to not rely on the text output
format.
llvm-svn: 204489
 | 
| | 
| 
| 
| 
| 
|  | 
An unnamed global in llvm still produces a regular symbol.
llvm-svn: 204488
 | 
| | 
| 
| 
| 
| 
|  | 
NUM_OPENMP_DEFAULT_KINDS <= 1.
llvm-svn: 204487
 | 
| | 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
|  | 
llvm-svn: 204446
 | 
| | 
| 
| 
| 
| 
|  | 
We now have both polyhedral dead code elimination as well as LNT buildbots.
llvm-svn: 204445
 | 
| | 
| 
| 
|  | 
llvm-svn: 204444
 | 
| | 
| 
| 
|  | 
llvm-svn: 204443
 | 
| | 
| 
| 
|  | 
llvm-svn: 204442
 | 
| | 
| 
| 
|  | 
llvm-svn: 204441
 | 
| | 
| 
| 
|  | 
llvm-svn: 204440
 |