Although their name and location suggests otherwise, these libraries are
not really plugins but rather support the real plugins.

This is still failing spectacularly on the Windows bot and I still have
no clue what's going on.

sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h,td}

I failed to copy it when I moved this in
b62de210

 - Don't initialize NativePDB.
 - Initialize ProcessWindows after any Process*Core plugins.
 - Don't initialize DynamicLoaderDarwinKernel on non-Darwin platforms.

rdar://58855712

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

Reviewers: t.p.northover

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

Summary: Patch originally by Tim Northover

Reviewers: t.p.northover

Subscribers: EricWF, hiraditya, modocache, llvm-commits

Tags: #llvm

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

Reviewers: t.p.northover

Subscribers: cfe-commits, llvm-commits

Tags: #clang

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

This patch changes the way we initialize and terminate the plugins in
the system initializer. It uses an approach similar to LLVM's
TARGETS_TO_BUILD with a def file that enumerates the plugins.

The previously landed patch got reverted because it was lacking:

 (1) A plugin definition for the Objective-C language runtime,
 (2) The dependency between the Static and WASM dynamic loader,
 (3) Explicit initialization of ScriptInterpreterNone for lldb-test.

All issues have been addressed in this patch.

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

In some systems, such as RISC-V, atomic support requires explicit linking
against '-latomic' (see https://github.com/riscv/riscv-gcc/issues/12).

Reviewers: davezarzycki, hhb, beanz, jfb, JDevlieghere
Reviewed By: beanz, JDevlieghere
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69003

For a file in WebKit, this brings the time spent in LiveDebugValues down
from 16 minutes to 2 minutes. The reduction comes from iterating the set
of open variable locations just once in transferRegisterDef. Post-patch,
the most expensive item inside of transferRegisterDef is a call to
VarLoc::isDescribedByReg, which we have to do.

Testing: I built LNT using the Os-g cmake cache with & without this
patch, then diffed the object files to verify there was no binary diff.

rdar://59446577

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

This re-commits https://reviews.llvm.org/D70927, which I reverted in
https://reviews.llvm.org/rG28213680b2a7d1fdeea16aa3f3a368879472c72a due
to a buildbot error:
http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/13251

I no longer include a test case that appears to crash when built with the
buildbot's compiler, GCC 5.4.0.

We have one title in every doc which corresponds to `#`, in the some
there are multiple and it is expected to be h1 headers (visual elements
rather than organizational). Indent every nesting by one in all of the
docs with multiple titles.

Also fixing trailing whitespace.

This temporarily reverts commit 7d6da329
because it's causing test failures on the bots.

Treat unknown address spaces as global

We don't need FrameInfo's concept of the stack alignment. We just
need to tell it the desired alignment. Which in this case is 2.

AArch64 handles this pattern in their lowering code. By emitting
CMN. ARM handles it as an isel pattern.

This reverts commit https://reviews.llvm.org/rG449a13509190b1c57e5fcf5cd7e8f0f647f564b4,
due to buildbot failures such as
http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/13251.

This required legal and regbankselected MIR for seemingly no
reason. For AMDGPU this wouldn't see legalized G_GLOBAL_VALUEs.

I readily admit that I don't know why this fixes the modules build, but
it seems to get things building again. Previously I saw the error
message:

http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/9404/consoleFull#-361314398a1ca8a51-895e-46c6-af87-ce24fa4cd561

```
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/IR/IRBuilderFolder.h:18:10: fatal error: cyclic dependency in module 'LLVM_intrinsic_gen': LLVM_intrinsic_gen -> LLVM_IR -> LLVM_intrinsic_gen

         ^
While building module 'LLVM_intrinsic_gen' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/lib/IR/IRBuilder.cpp:14:
In file included from <module-includes>:1:
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/IR/Argument.h:19:10: fatal error: could not build module 'LLVM_IR'
 ~~~~~~~~^~~~~~~~~~~~~~~~~
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/lib/IR/IRBuilder.cpp:14:10: fatal error: could not build module 'LLVM_intrinsic_gen'
```

And reproduced with:

cmake -G Ninja /Users/vsk/src/llvm-backup-master/llvm -DCLANG_ENABLE_ARCMT=Off -DCLANG_ENABLE_STATIC_ANALYZER=Off -DLLVM_ENABLE_PROJECTS='clang;clang-tools-extra;lld;libcxx;libcxxabi;compiler-rt;libunwind;lldb' -DLLDB_USE_SYSTEM_DEBUGSERVER=On -DCMAKE_BUILD_TYPE=RelWithDebInfo -DLLVM_ENABLE_ASSERTIONS=On -DLLVM_ENABLE_MODULES=On

ProcessPOSIX and ProcessLinux are not real plugins and should not be
marked as such. This should fix the Linux bots.

AMDGPUCodeGenPrepare expands this most of the time, but not always. We
will always at least need a fallback option here. This is the 3rd
implementation of the same expansion in the backend. Eventually I
would like to eliminate the IR expansion (and the DAG version
obviously).

Currently the new legalizer path produces a better result, since the
IR expansion results in extra operations which need to be combined
out. Notably, the IR expansion results in multiplies by 0.

The check for 'HAVE_CXX_ATOMICS_WITHOUT_LIB' may create false
positives in RISC-V. This is reproducible when compiling LLVM natively
using GCC on a rv64gc (rv64imafdgc) host. Due to the 'A' (atomic)
extension, g++ replaces calls to libatomic operations on the
std::atomic<int> type with the native hardware instructions. As a
result, the compilation succeeds and the build system thinks it
doesn't need to pass '-latomic'.

Improve the reliability of the 'HAVE_CXX_ATOMICS_WITHOUT_LIB' test in
two steps:

1. Force a pre-increment on x (++x), which should force a call to a
libatomic function;

2. Because step 1 would resolve the increment to 'amoadd.w.aq' under
the 'A' extension, force the same operation on sub-word types, for
which there is no hardware support.

Reviewers: jfb, hintonda, smeenai, mgorny, JDevlieghere, jyknight
Reviewed By: jfb
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68964

Summary:
The first in a series of patches that ports the LLVM coroutines passes
to the new pass manager infrastructure. This patch implements
'coro-early'.

NB: All coroutines passes begin by checking that coroutine intrinsics are
declared within the LLVM IR module they're operating on. To do so, they call
`coro::declaresIntrinsics`. The next 3 patches in this series, which add new
pass manager implementations of the 'coro-split', 'coro-elide', and
'coro-cleanup' passes, use a similar pattern as the one used here: a static
function is shared across both old and new passes to detect if relevant
coroutine intrinsics are delcared. To make this pattern easier to read, this
patch adds `const` keywords to the parameters of `coro::declaresIntrinsics`.

Reviewers: GorNishanov, lewissbaker, junparser, chandlerc, deadalnix, wenlei

Reviewed By: wenlei

Subscribers: ychen, wenlei, EricWF, hiraditya, llvm-commits

Tags: #llvm

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

This should fix the unresolved external symbol error.

mutateStrictFPToFP can delete the node and replace it with another with the same
value which can later cause problems, and returning the result of
mutateStrictFPToFP doesn't work because SelectionDAGLegalize expects that the
returned value has the same number of results as the original. Instead handle
things by doing the mutation manually.

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