- FuncNode::findBlock traverses the function every time. Avoid using it,
  and keep a cache of block addresses in DataFlowGraph instead.
- The operator[] in the map of definition stacks was very slow. Replace
  the map with unordered_map.

llvm-svn: 276429

Summary:
When compiling the runtime library with clang we get warnings like:
```
error: passing an object that undergoes default argument promotion to 'va_start' has undefined behavior [-Werror,-Wvarargs]
    va_start( args, id );
                    ^
note: parameter of type 'kmp_i18n_id_t' (aka 'kmp_i18n_id') is declared here
    kmp_i18n_id_t id,
```
My understanding is that the va_start macro only gets the promoted type so it won't know what was the exact type of the argument, which can potentially not work for some targets given that the implementation of the the calling convention could not be done properly.

This patch fixes that by using a built-in type in the function signature.

Reviewers: tlwilmar, jlpeyton, AndreyChurbanov

Subscribers: arpith-jacob, carlo.bertolli, caomhin, openmp-commits

Differential Revision: https://reviews.llvm.org/D22427

llvm-svn: 276428

This facilitates code reuse between the builder classes and the
"frozen" read only versions of the classes used for parsing
existing PDB files.

llvm-svn: 276427

This implements support for writing compiland and compiland source
file info to a binary PDB.  This is tested by adding support for
dumping these fields from an existing PDB to yaml, reading them
back in, and dumping them again and verifying the values are as
expected.

llvm-svn: 276426

llvm-svn: 276425

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Acked-By: Aaron Watry <awatry@gmail.com>
llvm-svn: 276423

llvm-svn: 276422

llvm-svn: 276419

As discussed on D22460, I've updated the vbroadcastf128 pd256/ps256 builtins to map directly to generic IR - load+splat a 128-bit vector to both lanes of a 256-bit vector.

Fix for PR28657.

llvm-svn: 276417

As reported on PR26235, we don't currently make use of the VBROADCASTF128/VBROADCASTI128 instructions (or the AVX512 equivalents) to load+splat a 128-bit vector to both lanes of a 256-bit vector.

This patch enables lowering from subvector insertion/concatenation patterns and auto-upgrades the llvm.x86.avx.vbroadcastf128.pd.256 / llvm.x86.avx.vbroadcastf128.ps.256 intrinsics to match.

We could possibly investigate using VBROADCASTF128/VBROADCASTI128 to load repeated constants as well (similar to how we already do for scalar broadcasts).

Reapplied with fix for PR28657 - removed intrinsic definitions (clang companion patch to be be submitted shortly).

Differential Revision: https://reviews.llvm.org/D22460

llvm-svn: 276416

Second try for r276408

llvm-svn: 276415

This patch introduces:

* TypeLoc visiting, which helps a lot in renaming types
* NestedNameSpecifierLoc visiting (through getting them via ASTMatcher at the moment, though, because RecursiveASTVisitor<T>::VisitNestedNameSpecifierLoc isn't implemented), which helps to treat nested names correctly
* better code formatting and refactoring
* bunch of tests

Reviewers: alexfh

Differential revision: https://reviews.llvm.org/D22465

llvm-svn: 276414

Tests fail on clang-x64-ninja-win7 due to too narrow expectation.

llvm-svn: 276413

"Incorrect" file name seen on Android whene the main executable is
called "app_process32" (or 64) but the linker specifies the package
name (e.g. com.android.calculator2). Additionally it can be present
in case of some linker bugs.

This CL adds logic to try to fetch the correct file name from the proc
file system based on the base address sepcified by the linker in case
we are failed to load the module by name.

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

llvm-svn: 276411

llvm-svn: 276410

The llvm-cov ‘report' command displays a summary of the coverage of a binary file.
The summary report currently only includes covered regions and covered functions.
This patch adds the coverage of lines in the summary report.

Differential Revision: https://reviews.llvm.org/D22569

llvm-svn: 276409

Flags slicing of member variables or vtable. See:

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es63-dont-slice
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c145-access-polymorphic-objects-through-pointers-and-references

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

llvm-svn: 276408

This feature was lost in r276197.

llvm-svn: 276407

Summary:
The binary layout of prstatus and prpsinfo was wrong.
Some of the member variables where not aligned properly
and others where with a wrong type (e.g. the time related
stuff in prstatus).

I used the structs defined in bfd in binutils to see what the layout
of the elf-core format in these section is.
(https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/hosts/x86-64linux.h;h=4e420a1f2081dd3b51f5d6b7a8e4093580f5cdb5;hb=master)
Note: those structures are only for x86 64 bit elf-core files

This shouldn't have any impact on the functionality, because
lldb actually uses only a few of the member variables of those structs
and they are with a correct type and alignment.

I found this while trying to add/fix the support for
i386 core files (https://llvm.org/bugs/show_bug.cgi?id=26947)

Reviewers: labath

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D22628
Author: Dimitar Vlahovski <dvlahovski@google.com>

llvm-svn: 276406

It caused PR28657.

This reverts commit r276281.

llvm-svn: 276405

Summary:

When giving the following command:
% llvm-cov report -instr-profile=default.profraw

llvm-cov will give the following error message:

>llvm-cov report: Not enough positional command line arguments specified!
>Must specify at least 1 positional arguments: See: orbis-llvm-cov report -help

This patch changes the error message from  '1 positional arguments'
to '1 positional argument'.

Differential Revision: https://reviews.llvm.org/D22621

llvm-svn: 276404

llvm-svn: 276403

Allowing this variable to be cached makes it possible to repair the MIPS
buildbots in lieu of either fixing the mips64 sanitizer issues or fixing the
detection of mips64 support (which I think was changed by r268977 but didn't
take effect on this buildbot until the last couple days) so that it returns to
not being built on these buildbots.

llvm-svn: 276402

llvm-svn: 276401

Note the == on the last line, this isn't a strict-weak ordering.

llvm-svn: 276400

functions so that the size computation is available not only in ConstantIslands
but in other passes as well.

Differential Revision: https://reviews.llvm.org/D22640

llvm-svn: 276399

llvm-svn: 276398

Differential Revision: https://reviews.llvm.org/D19906

llvm-svn: 276397

Run the NVPTX backend over the GPUModule IR and write the resulting assembly
code in a string.

To work correctly, it is important to invalidate analysis results that still
reference the IR in the kernel module. Hence, this change clears all references
to dominators, loop info, and scalar evolution.

Finally, the NVPTX backend has troubles to generate code for various special
floating point types (not surprising), but also for uncommon integer types. This
commit does not resolve these issues, but pulls out problematic test cases into
separate files to XFAIL them individually and resolve them in future (not
immediate) changes one by one.

llvm-svn: 276396

llvm-svn: 276395

llvm-svn: 276394

llvm-svn: 276393

llvm-svn: 276392

llvm-svn: 276391

llvm-svn: 276390

Just because we can constant fold the result of an instruction does not
imply that we can delete the instruction.  It may have side effects.

This fixes PR28655.

llvm-svn: 276389

llvm-svn: 276388

llvm-svn: 276387

llvm-svn: 276386

llvm-svn: 276385