This reapplies bb27e456 (SimpleRemoteEPC
support) and 2269a941 (#include <mutex>
fix) with further fixes to support building with LLVM_ENABLE_THREADS=Off.

This comes from lengthy discussion between Quuxplusone and ldionne over on D108216.
Right now, libc++ uses a "SCARY metaprogramming" version of _EnableIf that bypasses
all of Clang's clever diagnostic stuff and thus produces bad diagnostics. My recent
benchmarks ( https://quuxplusone.github.io/blog/2021/09/04/enable-if-benchmark/ )
have determined that the SCARYness is not buying us any speedup; therefore we are
happy to drop it and go back to using the standard std::enable_if for all our
SFINAE needs. However, we don't want to type out typename std::enable_if<X>::type
all over the library; we want to use an alias template. And we can't use
std::enable_if_t because we need a solution that works in C++11, and we do not
provide std::enable_if_t in C++11.

Therefore, D109435 switches us from SCARY `_EnableIf` to a normal `__enable_if_t`
(at least in C++11 mode, and possibly everywhere for consistency).
Simultaneously, this Clang patch enables the good diagnostics for `__enable_if_t`.
We don't need to enable good diagnostics for `_EnableIf` because the name
`_EnableIf` has only ever been used for the SCARY version where the good diagnostics
don't trigger anyway.

(Btw, this existing code is all sorts of broken, theoretically speaking.
I filed https://bugs.llvm.org/show_bug.cgi?id=51696 about it last week.
So if someone wants to use this PR as an excuse to go down the rabbit hole
and fix it for real, that would be cool too.)

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

Some functions in cxa_exception_storage.cpp have incorrect indentation
of braces; fix them.
Original patch by Zhouyi Zhou <zhouzhouyi@gmail.com>

Also, remove a line of commented-out (and no-longer-possible-to-compile)
code. That thread-safe-static initialization of `init` was replaced
with the call to pthread_once directly above it, back in 2012.

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

This regenerates some of the tests that had very-close-to-updated check
line already, in order to make them more maintainable.

Pass the access type to getPtrStride(), so it is not determined
from the pointer element type. Many cases still fetch the element
type at a higher level though, so this only partially addresses
the issue.

https://reviews.llvm.org/D47381 / eb46c95c
changed the triples set up by GetHostTriple.cmake for i686 MSVC
from i686-pc-win32 to i686-pc-windows-msvc without changing
the corresponding condition in llvm-shlib.

Since then, the 32 bit x86 build of LLVM-C.dll has contained no
exported symbols at all.

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

Follow-up for post-commit suggestion on:
28afaed6

The comments were partly copied from the original
code, but not updated to match the new code.

This code manually constructs the intrinsic name, so we need to
use p0 instead of p0i8 in opaque pointer mode.

This is a translation of the existing code to handle the intrinsics
and another step towards D98152.

https://alive2.llvm.org/ce/z/jA7eBC

This pattern is already handled by underlying folds if there are
less uses, so the minimal tests in this case have extra uses.

The larger cmyk tests show the motivation - when combined with
other folds, we invert a larger sequence and eliminate 'not' ops.

TestDyldLaunchLinux.py has been recently added and is failing on LLDB
Arm/Linux buildbot. I am marking it skip till I come back and look at
it in more detail.

Like the shuffle, we should treat the select delayed so that
all constants can be resolved.

Reviewed By: efriedma

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

Noticed while trying to improve generic reduction costs via the D103695 helper script. Confirmed with Intel AoM / Agner / InstLatX64.

Noticed while trying to improve generic reduction costs via the D103695 helper script. Confirmed with Intel AoM / Agner / InstLatX64.

We set the LoadUOps argument a lot more frequently that LoadLat, by swapping them we can simplify a number of declarations.

Reviewed By: LuoYuanke

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

This reverts commit 5629afea ("[ORC] Add missing
include."), and bb27e456 ("[ORC] Add
SimpleRemoteEPC: ExecutorProcessControl over SPS + abstract transport.").

The SimpleRemoteEPC patch currently assumes availability of threads, and needs
to be rewritten with LLVM_ENABLE_THREADS guards.

SimpleRemoteEPC is an ExecutorProcessControl implementation (with corresponding
new server class) that uses ORC SimplePackedSerialization (SPS) to serialize and
deserialize EPC-messages to/from byte-buffers. The byte-buffers are sent and
received via a new SimpleRemoteEPCTransport interface that can be implemented to
run SimpleRemoteEPC over whatever underlying transport system (IPC, RPC, network
sockets, etc.) best suits your use case.

The SimpleRemoteEPCServer class provides executor-side support. It uses a
customizable SimpleRemoteEPCServer::Dispatcher object to dispatch wrapper
function calls to prevent the RPC thread from being blocked (a problem in some
earlier remote-JIT server implementations). Almost all functionality (beyond the
bare basics needed to bootstrap) is implemented as wrapper functions to keep the
implementation simple and uniform.

Compared to previous remote JIT utilities (OrcRemoteTarget*,
OrcRPCExecutorProcessControl), more consideration has been given to
disconnection and error handling behavior: Graceful disconnection is now always
initiated by the ORC side of the connection, and failure at either end (or in
the transport) will result in Errors being delivered to both ends to enable
controlled tear-down of the JIT and Executor (in the Executor's case this means
"as controlled as the JIT'd code allows").

The introduction of SimpleRemoteEPC will allow us to remove other remote-JIT
support from ORC (including the legacy OrcRemoteTarget* code used by lli, and
the OrcRPCExecutorProcessControl and OrcRPCEPCServer classes), and then remove
ORC RPC itself.

The llvm-jitlink and llvm-jitlink-executor tools have been updated to use
SimpleRemoteEPC over file descriptors. Future commits will move lli and other
tools and example code to this system, and remove ORC RPC.

As of this commit:
  https://github.com/llvm/llvm-project/commit/307b1fdd

If either of those scripts are invoked with python 2, neither works due to:
  "TypeError: write() argument 1 must be unicode, not str"

And if rename_check.py is invoked with python 3:
  "ValueError: binary mode doesn't take an encoding argument"
(referring to `with io.open(filename, 'wb', encoding='utf8') as f:`), and

Another issue in rename_check.py in python 2:
  "TypeError: list object is not an iterator"
(referring to `next(filter( ... os.listdir(old_module_path)))`)

(so, rename_check doesn't work with either 2 or 3, and add_new_check
doesn't work with 2, but does work with 3)

I ran these steps to test both python versions:
(manually - appears to be the "status quo" for these files)

  python3 clang-tools-extra/clang-tidy/add_new_check.py readability ggggg
  python3 clang-tools-extra/clang-tidy/rename_check.py readability-ggggg readability-hhhhh

  git checkou...

When we have full-fp16 support, we should (manually select) s16 G_FCONSTANT to
a constant pool load.

Add support for that to `emitLoadFromConstantPool` + the existing constant
selection code.

Also tidy up the constant selection code a little. There were some out-of-date
comments + some dead code.

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

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

Refactors copyBlockContentToWorkingMemory to use offsets rather than direct
pointers to working memory. This simplifies the problem of maintaining
alignments between blocks in working memory, without requiring the working
memory itself to be aligned.

Since the ORC runtime and LLVM are no longer sharing SPS code (the ORC runtime
has its own copy) there is no reason to keep these separate.

This allows these classes to be created during EPC construction, before an
ExecutionSession is available.

Revert "Revert "[AArch64][SVE][InstCombine] Canonicalize aarch64_sve_dup_x intrinsic to IR splat operation""

This reverts commit eee7d225.
Effectively relanding 98c37247
after fixing the failing tests.

Change-Id: I5d7461aeb820a2d5f1895457d824a8de4d316ee5

This makes it clear that this only has an effect if you use the all
build target.

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

In macOS 12, the symbol name for the dyld_all_image_infos struct
in dyld has a namespace qualifier.  Search for it without qualification,
then with qualification when doing a by-name search.  (lldb will
only search for it by name when loading a user process Mach-O corefile)

rdar://76270013

Commits 58494c85, f6bc6145, and 0fc27ef1 added special
handlings for K&R C function definitions and caused some
JavaScript/TypeScript regressions which were addressed in D107267,
D108538, and D108620. This patch would have prevented these known
regressions and will fix any unknown ones.

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

This patch introduces the flags `-fopenmp-target-debug` and
`-fopenmp-target-debug=` to set the value of a global in the device.
This will be used to enable or disable debugging features statically in
the device runtime library.

Reviewed By: jdoerfert

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

We peform runtime folding, but do not currently emit remarks when it is
performed. This is because it comes from the runtime library and is
beyond the users control. However, people may still wish to view  this
and similar information easily, so we can enable this behaviour using a
special flag to enable verbose remarks.

Reviewed By: jdoerfert

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

The defintion of OFFLOAD_SUCCESS and OFFLOAD_FAIL used in plugin APIs and libomptarget public APIs are not consistent.
Create __tgt_target_return_t for libomptarget public APIs.

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