llvm-svn: 275784

Create LLVM-IR for all host-side control flow of a given GPU AST. We implement
this by introducing a new GPUNodeBuilder class derived from IslNodeBuilder.  The
IslNodeBuilder will take care of generating all general-purpose ast nodes, but
we provide our own createUser implementation to handle the different GPU
specific user statements. For now, we just skip any user statement and only
generate a host-code sceleton, but in subsequent commits we will add handling of
normal ScopStmt's performing computations, kernel calls, as well as host-device
data transfers. We will also introduce run-time check generation and LICM in
subsequent commits.

llvm-svn: 275783

Summary:
We've run into this problem when the test errored out so early (because it could not connect to
the remote device), that the code in D20193 did not catch the error. This resulted in the test
suite reporting success with 0 tests being run.

This patch makes sure that any non-zero exit code from the inferior process gets reported as an
error. Basically I expand the concept of "exceptional exits", which was previously being used for
signals to cover these cases as well.

Reviewers: tfiala, zturner

Subscribers: lldb-commits

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

llvm-svn: 275782

after inserting a missing header.

Summary:

A small improvement: Don't print newline character at the end of message, so
that users don't have to type ENTER manually after running the python script.

Reviewers: bkramer

Subscribers: djasper, klimek, cfe-commits

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

llvm-svn: 275781

Reviewers: dsanders

Subscribers: slthakur, jaydeep, llvm-commits, Sanitizers

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

llvm-svn: 275780

Summary:
The work item intrinsics are not available for the shader
calling conventions. And even if we did hook them up most
shader stages haves some extra restrictions on the amount
of available LDS.

Reviewers: tstellarAMD, arsenm

Subscribers: nhaehnle, arsenm, llvm-commits, kzhuravl

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

llvm-svn: 275779

Summary:
This patch fills in the implementation of GetMemoryRegions() on the Windows live process and minidump implementations of lldb_private::Process (ProcessWindowsLive::GetMemoryRegionInfo and ProcessWinMiniDump::Impl::GetMemoryRegionInfo.) The GetMemoryRegions API was added under: http://reviews.llvm.org/D20565

The existing Windows implementations didn’t fill in the start and end addresses within MemoryRegionInfo. This patch fixes that and adds support for the new mapped flag on MemoryRegionInfo that says whether a memory range is mapped into the process address space or not.

The behaviour of both live and core implementations should match the behaviour documented on Process::GetMemoryRegionInfo (in Process.h) which in turn should match the behaviour of the qMemoryRegionInfo query documented in lldb-gdb-remote.txt.

Reviewers: clayborg, amccarth

Subscribers: amccarth, lldb-commits

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

llvm-svn: 275778

llvm-svn: 275777

The current logic for handling inline asm operands in DAGToDAGISel interprets
the operands by looking for constants, which should represent the flags
describing the kind of operand we're dealing with (immediate, memory, register
def etc). The operands representing actual data are skipped only if they are
non-const, with the exception of immediate operands which are skipped explicitly
when a flag describing an immediate is found.

The oversight is that memory operands may be const too (e.g. for device drivers
reading a fixed address), so we should explicitly skip the operand following a
flag describing a memory operand. If we don't, we risk interpreting that
constant as a flag, which is definitely not intended.

Fixes PR26038

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

llvm-svn: 275776

llvm-svn: 275775

llvm-svn: 275774

At higher optimization levels, we generate the libcall for DIVREM_Ix, which is
fine: aeabi_{u|i}divmod. At -O0 we generate the one for REM_Ix, which is the
default {u}mod{q|h|s|d}i3.

This commit makes sure that we don't generate REM_Ix calls for ABIs that
don't support them (i.e. where we need to use DIVREM_Ix instead). This is
achieved by bailing out of FastISel, which can't handle non-double multi-reg
returns, and letting the legalization infrastructure expand the REM_Ix calls.

It also updates the divmod-eabi.ll test to run under -O0 as well, and adds some
Windows checks to it to make sure we don't break things for it.

Fixes PR27068

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

llvm-svn: 275773

Constructing a std::locale object from an empty string selects the language
from the current environment variables. If the environment variables name
a locale that doesn't exist, or isn't installed, then the construction of
facets using that locale may throw.

This patch removes tests that use 'std::locale l("")'.

The optimal solution would be to manually set the environment variables
in the test. Unfortunately there is no portable way to do this.

llvm-svn: 275772

llvm-svn: 275771

llvm-svn: 275770

llvm-svn: 275769

llvm-svn: 275768

llvm-svn: 275767

[X86] Add more AVX512 instructions to X86InstrInfo::isHighLatencyDef. Also add all packed fp division instructions.

llvm-svn: 275766

[X86] Add AVX512 load opcodes and a couple AVX load opcodes to X86InstrInfo::areLoadsFromSameBasePtr.

llvm-svn: 275765

llvm-svn: 275764

Ideally we would use VEX encoded moves instead of EVEX if the high 16 registers aren't referenced, but this a good first step.

llvm-svn: 275763

llvm-svn: 275762

While debugging GVNHoist, I found it confusing that the entries in a
VNtoInsns were not always value numbers.  They _usually_ were except for
StoreInst in which case they were a hash of two different value numbers.

This leads to two observations:
- It is more difficult to debug things when the semantic contents of
  VNtoInsns changes over time.
- Using a single value number is not much cheaper, the value of
  VNtoInsns is a SmallVector.
- It is not immediately clear what the algorithm would do if there were
  hash collisions in the StoreInst case.

Using a DenseMap of std::pair sidesteps all of this.

N.B.  The changes in the test were due their sensitivity to the
iteration order of VNtoInsns which has changed.

llvm-svn: 275761

man page for mkdir says: "If the parent directory has the set-group-ID bit set,
then so will the newly created directory."

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

llvm-svn: 275760

This patch updates the way libc++ handles checking for libatomic, in part
to prepare for https://reviews.llvm.org/D22073.

Changes:
* 'LIBCXX_HAS_ATOMIC_LIB' is now set whenever libatomic is available even libc++
   doesn't need to manually link it.
* 'LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB' is now used to detect when libatomic
   needs to be manually linked.
* 'LIBCXX_HAS_ATOMIC_LIB' now adds 'libatomic' as a available feature in the
   test suite.

llvm-svn: 275759

Don't make the test/tools/llvm-cov/demangle.test depend on the order in
which symbols are seen, or on the exact formatting llvm-cov emits after
a symbol is printed. This is an attempt to fix a Windows bot failure:

  http://lab.llvm.org:8011/builders/clang-x86-win2008-selfhost/builds/9141

I don't know what the root cause of the failure is, or why the
showTemplateInstantiations test doesn't fail in the same way on the
Windows bots. However, this measure can't hurt, and it'll at least get
me on the blamelists again.

llvm-svn: 275758

llvm-svn: 275757

This reverts also r275029, "Update Clang tests after adding inference for the returned argument attribute"

It broke LTO build. Seems miscompilation.

llvm-svn: 275756

llvm-svn: 275754

llvm-svn: 275753

llvm-svn: 275752

llvm-svn: 275751

llvm-svn: 275750

This patch does the following:

* It renames `_LIBCPP_TRIVIAL_PAIR_COPY_CTOR` to `_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR`.
* It automatically enables this option on FreeBSD in ABI V1, since that's the current ABI FreeBSD ships.
* It cleans up the handling of this option in `std::pair`.

I would like the sign off from the FreeBSD maintainers. They will no longer need to keep their `__config` changes downstream.

I'm still hoping to come up with a better way to maintain the ABI without needing these constructors.

Reviewed in https://reviews.llvm.org/D21329

llvm-svn: 275749

llvm-svn: 275748

In the last patch for --trace-symbol, I introduced a new symbol type
PlaceholderKind and store it to SymVector storage. It made all code
that iterates over SymVector to recognize and skip PlaceholderKind
symbols. I found that that's annoying.

In this patch, I removed PlaceholderKind and stop storing them to SymVector.
Now the information whether a symbol is being watched by --trace-symbol
is stored to the Symtab hash table.

llvm-svn: 275747

SymVector contains all symbols, so we can iterate either Symtab or SymVector
to visit all symbols. Iterating over SymVector makes the next change for
--trace-symbol possible.

llvm-svn: 275746

This patch upgrades <tuple> to be C++17 compliant by implementing:

* tuple_size_v: This was forgotten when implementing the other _v traits.
* std::apply: This was added via LFTS v1 in p0220r1.
* std::make_from_tuple: This was added in p0209r2.

llvm-svn: 275745

HoistedCtr cannot be a mutated global variable, that will open us up to
races between threads compiling code in parallel.

llvm-svn: 275744