[X86][AVX] Fold CONCAT(HOP(X,Y),HOP(Z,W)) -> HOP(CONCAT(X,Z),CONCAT(Y,W)) for float types

We can now enable this for AVX1 targets can now assist with canonicalizeShuffleMaskWithHorizOp cleanup.

There's still a few missed opportunities for merging subvector insert/extracts into shuffles, but they shouldn't cause any regressions now.

Revert "[PhaseOrdering] add test for memcpy removal (PR47114); NFC"

This reverts commit babb59496b540583c6951813d1e0b3abdea97e7d.

This test addition was queued up with some unrelated changes,
but it seems more likely that we need to fix something internal
to -memcpyopt. Also, I'm not sure if including target-specifc
attributes in a generic regression test dir will cause bot
problems.

[InstCombine] fold copysign with fabs/fneg operand

We already get this in the backend, but we need to do
it in IR too to consistently get yet more copysign
transforms.

[InstCombine] reduce code duplication; NFC

[InstCombine] add tests for copysign; NFC

[PhaseOrdering] add test for memcpy removal (PR47114); NFC

[StackSafety] Change how callee searched in index

Handle other than local linkage types.

[X86][SSE] Replace combineShuffleWithHorizOp with canonicalizeShuffleMaskWithHorizOp

Instead of just attempting to fold shuffle(HOP,HOP) for a specific target shuffle, make this part of combineX86ShufflesRecursively so we can perform this on the combined shuffle chain, which is particularly useful for recognising more cases of where we're performing multiple HOPs that can be merged and pre-AVX where we don't have good blend/unary target shuffle support.

Create strict aligned code for OpenBSD/arm64.

[X86] isRepeatedTargetShuffleMask - don't require specific MVT type. NFC.

Split the isRepeatedTargetShuffleMask into a wrapper variant that takes a MVT describing the mask width, and an internal version that just needs the raw mask element bit size.

This will be necessary for an upcoming change where the horizontal ops element width might not match the shuffle mask element width.

[llvm-libtool-darwin] Fix test on all host architectures

By default, if a universal binary has a slice matching the host
architecture, llvm-objdump will only print that slice, otherwise it'll
print all architectures. Explicitly pass `--arch all` to force it to
always print all architectures, as we want for this test.

[OpenMP][OMPBuilder] Adding support for `omp single`

This adds support for generating `omp single`, and necessary calls for
`copyprivate` clause.

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

[llvm-libtool-darwin] Speculative buildbot fix

http://lab.llvm.org:8011/builders/llvm-clang-win-x-armv7l is failing
this test. Attempt to explicitly use the Mach-O dump format as a
speculative fix.

[gn build] Port 577e58bcc75

[InlineAdvisor] New inliner advisor to replay inlining from optimization remarks

This change added a new inline advisor that takes optimization remarks from previous inlining as input, and provides the decision as advice so current inlining can replay inline decisions of a different compilation. Dwarf inline stack with line and discriminator is used as anchor for call sites including call context. The change can be useful for Inliner tuning as it provides a channel to allow external input for tweaking inline decisions. Existing alternatives like alwaysinline attribute is per-function, not per-callsite. Per-callsite inline intrinsic can be another solution (not yet existing), but it's intrusive to implement and also does not differentiate call context.

A switch -sample-profile-inline-replay=<inline_remarks_file> is added to hook up the new inline advisor with SampleProfileLoader's inline decision for replay. Since SampleProfileLoader does top-down inlining, inline decision can be specialized for each call context, hence we should be able to replay inlining accurately. However with a bottom-up inliner like CGSCC inlining, the replay can be limited due to lack of specialization for different call context. Apart from that limitation, the new inline advisor can still be used by regular CGSCC inliner later if needed for tuning purpose.

This is a resubmit of https://reviews.llvm.org/D83743

[ARC] Fix CodeGen/ARC/brcc.ll

[libomptarget] Implement host plugin for amdgpu

[libomptarget] Implement host plugin for amdgpu

Replacement for D71384. Primary difference is inlining the dependency on atmi
followed by extensive simplification and bugfixes. This is the latest version
from https://github.com/ROCm-Developer-Tools/amd-llvm-project/tree/aomp12 with
minor patches and a rename from hsa to amdgpu, on the basis that this can't be
used by other implementations of hsa without additional work.

This will not build unless the ROCM_DIR variable is passed so won't break other
builds. That variable is used to locate two amdgpu specific libraries that ship
as part of rocm:
libhsakmt at https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface
libhsa-runtime64 at https://github.com/RadeonOpenCompute/ROCR-Runtime
These libraries build from source. The build scripts in those repos are for
shared libraries, but can be adapted to statically link both into this plugin.

There are caveats.
- This works well enough to run various tests and benchmarks, and will be used
  to support the current clang bring up
- It is adequately thread safe for the above but there will be races remaining
- It is not stylistically correct for llvm, though has had clang-format run
- It has suboptimal memory management and locking strategies
- The debug printing / error handling is inconsistent

I would like to contribute this pretty much as-is and then improve it in-tree.
This would be advantagous because the aomp12 branch that was in use for fixing
this codebase has just been joined with the amd internal rocm dev process.

Reviewed By: jdoerfert

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

[JITLink][MachO] Use correct symbol scope when N_PEXT is set and N_EXT unset.

MachOLinkGraphBuilder has been treating these as hidden, but they should be
treated as local.

Symbols with N_PEXT set and N_EXT unset are produced when hidden symbols are
run through 'ld -r' without passing -keep_private_externs. They will show up
under 'nm -m' as "was private extern", hence the name of the test cases.

Testcase commited as relocatable object to ensure that the test suite doesn't
depend on having 'ld -r' available.

Slightly relax the regex on lld version in test (NFC)

This makes the test introduced in 537f5483fe4e more robust with respect
to the actual version number. The previous regex restricted the version
to start with a leading `1` which was overly restrictive.

[GlobalISel] Enable copy-propagation in post-legalizer combiner.

This cleans up copies that the legalizer or other combines leave around. They
can occasionally end up escaping as moves.

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

Refactor mlir-opt setup in a new helper function (NFC)

This will help refactoring some of the tools to prepare for the explicit registration of
Dialects.

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

[llvm-libtool-darwin] Use Optional operator overloads. NFC

Use operator bool instead of hasValue and operator* instead of getValue
to simplify the code slightly.

[gn build] Port 79298a50670

GlobalISel: Remove unnecessary llvm::

AMDGPU: Remove register class params from flat memory patterns

AMDGPU: Fix global atomic saddr operand class

AMDGPU: Remove slc from flat offset complex patterns

This was always set to 0. Use a default value of 0 in this context to
satisfy the instruction definition patterns. We can't unconditionally
use SLC with a default value of 0 due to limitations in TableGen's
handling of defaulted operands when followed by non-default operands.

AMDGPU: Fix matching wrong offsets for global atomic loads

These used signed offsets with a different size.

AMDGPU: Remove redundant FLAT complex patterns

These were identical to the non-atomic cases. I'm not sure why these
were ever separated.

AMDGPU: Correct definitions for global saddr instructions

The VGPR component is a 32-bit offset, not 64-bits.

I'm not sure what the correct syntax is for this. This maintains the
vaddr position and leaves saddr in the end "off" position. This is
particularly terrible for stores, since the operand order is now <vgpr
offset>, <data>, <sgpr base>, splitting the pointer operands. I
suppose this is a logical consequence from the mistake of not putting
the data operand first. I'm not sure what sp3 does.

AMDGPU: Remove SIFixupVectorISel pass

This was only used for matching the saddr addressing mode of global
instructions, but this was not implemented correctly. The instruction
definitions aren't even correct, and are defined as using a 64-bit
VGPR component. Eliminate this pass to enable correcting the
instruction definitions. A new matching implementation can work in
GlobalISel or relying on DAG divergence information for the base
address.

[NFC] Fix typo and variable names

[Attributor][NFC] Format code

[Attributor][NFC] Use indexes instead of iterator

When adding elements when iterating, the iterator will become
valid, which could cause errors. This fixes the issue by using
indexes instead of iterator.

Add support for C++20 concepts and decltype to modernize-use-trailing-return-type.

[TextAPI] update DriverKit string value

String value differed from downstream, where upstream doesn't depend on
casing difference.
<rdar://problem/67106257>

[MachOYAML] Move EmitFunc to an inner scope. NFC.

[Attributor] Use internalized version of non-exact functions

This patch internalize non-exact functions and replaces of their uses
with the internalized version. Doing this enables the analysis of
non-exact functions.

We can do this because some non-exact functions with the same name
whose linkage is `linkonce_odr` or `weak_odr` should have the same
semantics, so we can safely internalize and replace use of them (the
result of the other version of this function should be the same.).
Note that not all functions can be internalized, e.g., function with
`linkonce` or `weak` linkage.

For now when specified in commandline, we internalize all functions
that meet the requirements without calculating the cost of such
internalzation.

Reviewed By: jdoerfert

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

[DWARFYAML] Simplify isEmpty(). NFC.

On FreeBSD, add -pthread to ASan dynamic compile flags for tests

Otherwise, lots of these tests fail with a CHECK error similar to:

==12345==AddressSanitizer CHECK failed: compiler-rt/lib/asan/asan_posix.cpp:120 "((0)) == ((pthread_key_create(&tsd_key, destructor)))" (0x0, 0x4e)

This is because the default pthread stubs in FreeBSD's libc always
return failures (such as ENOSYS for pthread_key_create) in case the
pthread library is not linked in.

Reviewed By: arichardson

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

Reland "[SLC] sprintf(dst, "%s", str) -> strcpy(dst, str)"

Revert "Separate the Registration from Loading dialects in the Context"

This reverts commit 20563933875a9396c8ace9c9770ecf6a988c4ea6.

Build is broken on a few bots

Separate the Registration from Loading dialects in the Context

This changes the behavior of constructing MLIRContext to no longer load globally registered dialects on construction. Instead Dialects are only loaded explicitly on demand:
- the Parser is lazily loading Dialects in the context as it encounters them during parsing. This is the only purpose for registering dialects and not load them in the context.
- Passes are expected to declare the dialects they will create entity from (Operations, Attributes, or Types), and the PassManager is loading Dialects into the Context when starting a pipeline.

This changes simplifies the configuration of the registration: a compiler only need to load the dialect for the IR it will emit, and the optimizer is self-contained and load the required Dialects. For example in the Toy tutorial, the compiler only needs to load the Toy dialect in the Context, all the others (linalg, affine, std, LLVM, ...) are automatically loaded depending on the optimization pipeline enabled.

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

Revert "Separate the Registration from Loading dialects in the Context"

This was landed by accident, will reland with the right comments
addressed from the reviews.
Also revert dependent build fixes.

Revert "[SLC] sprintf(dst, "%s", str) -> strcpy(dst, str)"

This reverts commit 6dbf0cfcf789365493f70ae69df8a7a59be41c75.

That commit caused failed assertions, e.g. like this:

$ cat sprintf-strcpy.c
char *ptr; void func(void) { ptr += sprintf(ptr, "%s", ""); }

$ clang -c sprintf-strcpy.c -O2 -target x86_64-linux-gnu
clang: ../lib/IR/Value.cpp:473: void llvm::Value::doRAUW(llvm::Value*,
llvm::Value::ReplaceMetadataUses): Assertion `New->getType() ==
getType() && "replaceAllUses of value with new value of different
type!"' failed.

[lldb] Remove XFAIL from now passing TestPtrRefs/TestPtreRefsObjC

8fcfe2862fd4fde4793e232cfeebe6c5540c80a5 and
0cceb54366b406649fdfe7bb11b133ab96f3cd70 fixed those tests.

[Tests] Be consistent w/definition of statepoint-example

These tests use the statepoint-example builtin gc which expects address space #1 to the only non-integral address space.  The fact the test used as=0 happened to work, but was caught by a downstream assert.  (Literally years ago, I just happened to notice the XFAIL and fix it now.)

[Statepoint] Remove code related to inline operand bundles

This code becomes dead for valid IR after 48f4312 and a96fc46.  The reason for the test change is that the verifier reports the first verification error encountered, in some non-specified visit order.  By removing the verification code in gc.relocates for a statepoint with inline gc operands, I change the error the verifier reports.  And in one case, the checked for error is no longer possible with the bundle representation, so I simply delete the file.

Remove inline gc arguments from statepoints

The "gc-live" operand bundles were recently added, and all tests have been updated to use that format.  A migration period was provided, though it's worth noting these intrinsics are experimental, so formally there is no compatibile requirement.

This is an extension to a96fc46.  "gc-live" hadn't been implemented at the point that patch was initially posted.

[AMDGPU] Fix MAI ld/st hazard handling

It did not process hazard for ds_permute because it does not
load or store even though it is DS.

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

[SLC] Transform strncpy(dst, "text", C) to memcpy(dst, "text\0\0\0", C) for C <= 128 only

Transformation creates big strings for big C values, so bail out for C > 128.

Reviewed By: efriedma

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

[MSAN] Avoid dangling ActualFnStart when replacing instruction

This would be a problem if the entire instrumented function was a call
to
e.g. memcpy

Use FnPrologueEnd Instruction* instead of ActualFnStart BB*

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

[SVE] Lower fixed length vXi32/vXi64 SDIV to scalable vectors.

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

[SVE] Remove calls to VectorType::getNumElements from AggressiveInstCombine

Reviewed By: fpetrogalli

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

[libcxx/variant] Avoided variable name shadowing.

Remove deopt and gc transition arguments from gc.statepoint intrinsic

(Forgot to land this a couple of weeks back.)

In a recent series of changes, I've introduced support for using the respective operand bundle kinds on the statepoint. At the moment, code supports either/or, but there's no need to keep the old support around. For the moment, I am simply changing the specification and verifier to require zero length argument sets in the intrinsic.

The intrinsic itself is experimental. Given that, there's no forward serialization needed. The in tree uses and generation have already been updated to use the new operand bundle based forms, the only folks broken by the change will be those with frontends generating statepoints directly and the updates should be easy.

Why not go ahead and just remove the arguments entirely? Well, I plan to. But while working on this I've found that almost all of the arguments to the statepoint can be expressed via operand bundles or attributes. Given that, I'm planning a radical simplification of the arguments and figured I'd do one update not several small ones.

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

[test][LoopUnroll] Cleanup FullUnroll.ll

This is in preparation for enabling proper handling of optnone under the
NPM. Most optimizations won't run on an optnone function.

Previously the test would rely on lots of optimizations to optimize the
IR into a simple infinite loop. This is an optnone function, so clearly
that shouldn't be the case.

This IR was found by printing the module before the LoopFullUnrollerPass ran.

Reviewed By: asbirlea

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

[NewPM][optnone] Mark various passes as required

This was done by turning on -enable-npm-optnone and fixing failures.
That will be enabled in a follow-up change for ease of reverting.

Reviewed By: asbirlea

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

Fix TargetSubtargetInfo derivatives after D85165

[ELF] Re-initialize InputFile::isInGroup so that elf::link can be called more than once

[X86][MC][Target] Initial backend support a tune CPU to support -mtune

This patch implements initial backend support for a -mtune CPU controlled by a "tune-cpu" function attribute. If the attribute is not present X86 will use the resolved CPU from target-cpu attribute or command line.

This patch adds MC layer support a tune CPU. Each CPU now has two sets of features stored in their GenSubtargetInfo.inc tables . These features lists are passed separately to the Processor and ProcessorModel classes in tablegen. The tune list defaults to an empty list to avoid changes to non-X86. This annoyingly increases the size of static tables on all target as we now store 24 more bytes per CPU. I haven't quantified the overall impact, but I can if we're concerned.

One new test is added to X86 to show a few tuning features with mismatched tune-cpu and target-cpu/target-feature attributes to demonstrate independent control. Another new test is added to demonstrate that the scheduler model follows the tune CPU.

I have not added a -mtune to llc/opt or MC layer command line yet. With no attributes we'll just use the -mcpu for both. MC layer tools will always follow the normal CPU for tuning.

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

[TestPtrRefsObjC] Prefer `command script import`.

[TestPtrRefs] Prefer `command script import`.

Temporarily revert "[SCEVExpander] Add helper to clean up instrs inserted while expanding."

This reverts commit 7829c33084a7a5097533cf862daef521380c4e63. The assertion is triggering on some internal code. A reduced test case is in progress.

[SLC] sprintf(dst, "%s", str) -> strcpy(dst, str)

Transform sprintf(dst, "%s", str) -> strcpy(dst, str) if result is unused
Avoid sprintf(dest, "%s", str) -> llvm.memcpy(align 1 dest, align 1 str, strlen(str)+1) if optimizing for size.

Reviewed By: efriedma

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

[TableGen] Allow mnemonics with uppercase letters to be matched

The assembly parser "canonicalizes" the mnemonics it processes at an
early level by making them lowercase. The goal of this is presumably to
allow assembly to be case-insensitive. However, if one declares an
instruction with a mnemonic using uppercase letters, then it will
never get matched, since the generated lookup tables for the
AsmMatcherEmitter didn't lower() their inputs. This made it difficult to
have instructions that get printed using a mnemonic that includes
uppercase letters, since they could not be parsed.

To fix this problem, this patch adds a few calls to lower() to make the
lookup tables used in AsmMatcherEmitter be case-insensitive. This allows
instruction mnemonics with uppercase letters to be parsed.

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

[MSAN] Convert ActualFnStart to be a particular Instruction *, not BB

This allows us to add addtional instrumentation before the function start,
without splitting the first BB.

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

[docs] Add missing semicolon to example.

[MSAN] Reintroduce libatomic load/store instrumentation

Have the front-end use the `nounwind` attribute on atomic libcalls.
This prevents us from seeing `invoke __atomic_load` in MSAN, which
is problematic as it has no successor for instrumentation to be added.

[AIX] Generate unique module id based on Pid and timestamp

A unique module id, which is a part of sinit and sterm function names, is
necessary to be unique. However, `getUniqueModuleId` will fail if there is
no strong external symbol within a module. We turn to use Pid and timestamp
when this happens.

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

[x86] add tests for store merging (PR46662); NFC

Split Preprocessor/init.c test

Some parts of the test had been extracted into separate files previously.
This patch continues the trend and extracts few more large blocks.

This reduces wall time for the test from a single 14s-long test into a set of
smaller tests that can be run in parallel.

Before/after state of the check-clang tests are here:
https://gist.github.com/Artem-B/d0b05c2e98a49158c02de23f7f4f0279

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

[libcxx/variant] Introduce `switch`-based mechanism for `std::visit`.

This patch introduces mechanism for `std::visit` backed by `switch`.
The `switch` is structured such that it's a flattened manual vtable (an n-ary array).
The `switch` mechanism is enabled if `(1 * ... * vs.size()) < 1024`.

The following are performance numbers from the benchmarks added in D85419, tested on my 2017 Macbook Pro.

```
$ ./projects/libcxx/benchmarks/variant_visit_1.libcxx.out
2020-08-09 23:55:14
Running ./projects/libcxx/benchmarks/variant_visit_1.libcxx.out
Run on (8 X 3100 MHz CPU s)
CPU Caches:
  L1 Data 32K (x4)
  L1 Instruction 32K (x4)
  L2 Unified 262K (x4)
  L3 Unified 8388K (x1)
Load Average: 2.03, 2.36, 2.43
------------------------------------------------------------
Benchmark                 Time             CPU   Iterations
------------------------------------------------------------
BM_Visit<1, 1>        0.260 ns        0.260 ns   1000000000
BM_Visit<1, 2>         1.56 ns         1.56 ns    435925220
BM_Visit<1, 3>         1.55 ns         1.55 ns    444416228
BM_Visit<1, 4>         1.57 ns         1.57 ns    427951336
BM_Visit<1, 5>         1.57 ns         1.56 ns    444766371
BM_Visit<1, 6>         1.70 ns         1.68 ns    446639358
BM_Visit<1, 7>         1.64 ns         1.64 ns    400441630
BM_Visit<1, 8>         1.56 ns         1.56 ns    430729471
BM_Visit<1, 9>         1.58 ns         1.58 ns    449894596
BM_Visit<1, 10>        1.54 ns         1.54 ns    449660506
BM_Visit<1, 20>        1.56 ns         1.56 ns    450813074
BM_Visit<1, 30>        1.59 ns         1.59 ns    440032940
BM_Visit<1, 40>        1.59 ns         1.59 ns    443731656
BM_Visit<1, 50>        1.56 ns         1.56 ns    444709859
BM_Visit<1, 60>        1.59 ns         1.58 ns    439527320
BM_Visit<1, 70>        1.57 ns         1.57 ns    438450890
BM_Visit<1, 80>        1.58 ns         1.58 ns    443001525
BM_Visit<1, 90>        1.63 ns         1.62 ns    448456349
BM_Visit<1, 100>       1.57 ns         1.57 ns    445740630

$ ./projects/libcxx/benchmarks/variant_visit_2.libcxx.out
2020-08-09 23:59:35
Running ./projects/libcxx/benchmarks/variant_visit_2.libcxx.out
Run on (8 X 3100 MHz CPU s)
CPU Caches:
  L1 Data 32K (x4)
  L1 Instruction 32K (x4)
  L2 Unified 262K (x4)
  L3 Unified 8388K (x1)
Load Average: 1.40, 1.94, 2.22
-----------------------------------------------------------
Benchmark                Time             CPU   Iterations
-----------------------------------------------------------
BM_Visit<2, 1>       0.261 ns        0.260 ns   1000000000
BM_Visit<2, 2>        1.55 ns         1.54 ns    432844219
BM_Visit<2, 3>        1.30 ns         1.30 ns    532529974
BM_Visit<2, 4>        1.54 ns         1.54 ns    446055910
BM_Visit<2, 5>        1.31 ns         1.31 ns    531099680
BM_Visit<2, 6>        1.56 ns         1.56 ns    443203475
BM_Visit<2, 7>        1.29 ns         1.29 ns    526478087
BM_Visit<2, 8>        1.56 ns         1.56 ns    439000834
BM_Visit<2, 9>        1.30 ns         1.30 ns    528756817
BM_Visit<2, 10>       1.56 ns         1.55 ns    442923039
BM_Visit<2, 20>       1.35 ns         1.35 ns    517021072
BM_Visit<2, 30>       1.60 ns         1.59 ns    419724661
BM_Visit<2, 40>       1.45 ns         1.44 ns    472137163
BM_Visit<2, 50>       1.65 ns         1.65 ns    421389743

$ ./projects/libcxx/benchmarks/variant_visit_3.libcxx.out
2020-08-10 00:01:32
Running ./projects/libcxx/benchmarks/variant_visit_3.libcxx.out
Run on (8 X 3100 MHz CPU s)
CPU Caches:
  L1 Data 32K (x4)
  L1 Instruction 32K (x4)
  L2 Unified 262K (x4)
  L3 Unified 8388K (x1)
Load Average: 2.20, 2.01, 2.21
-----------------------------------------------------------
Benchmark                Time             CPU   Iterations
-----------------------------------------------------------
BM_Visit<3, 1>       0.272 ns        0.271 ns   1000000000
BM_Visit<3, 2>        1.87 ns         1.86 ns    361858090
BM_Visit<3, 3>        1.77 ns         1.77 ns    391192579
BM_Visit<3, 4>        1.84 ns         1.84 ns    374694223
BM_Visit<3, 5>        1.75 ns         1.75 ns    408270392
BM_Visit<3, 6>        1.88 ns         1.88 ns    378759185
BM_Visit<3, 7>        1.79 ns         1.79 ns    395498102
BM_Visit<3, 8>        1.85 ns         1.85 ns    371660366
BM_Visit<3, 9>        1.80 ns         1.80 ns    386872851
BM_Visit<3, 10>       1.84 ns         1.84 ns    362367606
BM_Visit<3, 15>       1.77 ns         1.77 ns    392060220
BM_Visit<3, 20>       1.85 ns         1.85 ns    379157188
```

```
$ ./projects/libcxx/benchmarks/variant_visit_1.libcxx.out
2020-08-10 00:05:57
Running ./projects/libcxx/benchmarks/variant_visit_1.libcxx.out
Run on (8 X 3100 MHz CPU s)
CPU Caches:
  L1 Data 32K (x4)
  L1 Instruction 32K (x4)
  L2 Unified 262K (x4)
  L3 Unified 8388K (x1)
Load Average: 2.27, 2.36, 2.34
------------------------------------------------------------
Benchmark                 Time             CPU   Iterations
------------------------------------------------------------
BM_Visit<1, 1>        0.271 ns        0.271 ns   1000000000
BM_Visit<1, 2>        0.269 ns        0.269 ns   1000000000
BM_Visit<1, 3>        0.271 ns        0.271 ns   1000000000
BM_Visit<1, 4>        0.270 ns        0.270 ns   1000000000
BM_Visit<1, 5>        0.269 ns        0.269 ns   1000000000
BM_Visit<1, 6>        0.270 ns        0.269 ns   1000000000
BM_Visit<1, 7>        0.265 ns        0.265 ns   1000000000
BM_Visit<1, 8>        0.269 ns        0.269 ns   1000000000
BM_Visit<1, 9>        0.268 ns        0.268 ns   1000000000
BM_Visit<1, 10>       0.269 ns        0.269 ns   1000000000
BM_Visit<1, 20>       0.267 ns        0.267 ns   1000000000
BM_Visit<1, 30>       0.272 ns        0.272 ns   1000000000
BM_Visit<1, 40>       0.268 ns        0.268 ns   1000000000
BM_Visit<1, 50>       0.268 ns        0.268 ns   1000000000
BM_Visit<1, 60>       0.268 ns        0.268 ns   1000000000
BM_Visit<1, 70>       0.269 ns        0.269 ns   1000000000
BM_Visit<1, 80>       0.266 ns        0.266 ns   1000000000
BM_Visit<1, 90>       0.268 ns        0.268 ns   1000000000
BM_Visit<1, 100>      0.267 ns        0.267 ns   1000000000

$ ./projects/libcxx/benchmarks/variant_visit_2.libcxx.out
2020-08-12 04:09:59
Running ./projects/libcxx/benchmarks/variant_visit_2.libcxx.out
Run on (8 X 3100 MHz CPU s)
CPU Caches:
  L1 Data 32K (x4)
  L1 Instruction 32K (x4)
  L2 Unified 262K (x4)
  L3 Unified 8388K (x1)
Load Average: 2.17, 4.20, 4.78
-----------------------------------------------------------
Benchmark                Time             CPU   Iterations
-----------------------------------------------------------
BM_Visit<2, 1>       0.302 ns        0.301 ns   1000000000
BM_Visit<2, 2>       0.297 ns        0.295 ns   1000000000
BM_Visit<2, 3>       0.353 ns        0.351 ns   1000000000
BM_Visit<2, 4>       0.276 ns        0.276 ns   1000000000
BM_Visit<2, 5>       0.285 ns        0.283 ns   1000000000
BM_Visit<2, 6>       0.290 ns        0.287 ns   1000000000
BM_Visit<2, 7>       0.282 ns        0.280 ns   1000000000
BM_Visit<2, 8>       0.290 ns        0.287 ns   1000000000
BM_Visit<2, 9>       0.291 ns        0.285 ns   1000000000
BM_Visit<2, 10>      0.293 ns        0.287 ns   1000000000
BM_Visit<2, 20>       1.70 ns         1.68 ns    391400375
BM_Visit<2, 30>       1.64 ns         1.63 ns    418925874
BM_Visit<2, 40>       1.63 ns         1.62 ns    423623677
BM_Visit<2, 50>       1.68 ns         1.67 ns    411687212

$ ./projects/libcxx/benchmarks/variant_visit_3.libcxx.out
2020-08-12 04:10:43
Running ./projects/libcxx/benchmarks/variant_visit_3.libcxx.out
Run on (8 X 3100 MHz CPU s)
CPU Caches:
  L1 Data 32K (x4)
  L1 Instruction 32K (x4)
  L2 Unified 262K (x4)
  L3 Unified 8388K (x1)
Load Average: 1.57, 3.76, 4.59
-----------------------------------------------------------
Benchmark                Time             CPU   Iterations
-----------------------------------------------------------
BM_Visit<3, 1>       0.271 ns        0.270 ns   1000000000
BM_Visit<3, 2>       0.344 ns        0.334 ns   1000000000
BM_Visit<3, 3>       0.347 ns        0.336 ns   1000000000
BM_Visit<3, 4>       0.300 ns        0.296 ns   1000000000
BM_Visit<3, 5>       0.290 ns        0.286 ns   1000000000
BM_Visit<3, 6>       0.272 ns        0.271 ns   1000000000
BM_Visit<3, 7>        1.72 ns         1.71 ns    415765841
BM_Visit<3, 8>        1.73 ns         1.72 ns    408909555
BM_Visit<3, 9>        2.16 ns         2.04 ns    380898485
BM_Visit<3, 10>       2.45 ns         2.40 ns    295714256
BM_Visit<3, 15>       1.92 ns         1.85 ns    375990332
BM_Visit<3, 20>       1.66 ns         1.65 ns    414456233
```

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

[StackSafety] Use ValueInfo in ParamAccess::Call

This avoid GUID lookup in Index.findSummaryInModule.
Follow up for D81242.

Reviewed By: tejohnson

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

[libc] Add restrict qualifiers to string library; give consistent naming scheme to TableGen files.

Reviewed By: sivachandra

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

[lld-macho] Emit load command LC_BUILD_VERSION

Reviewed By: int3

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

[MachO] Add skeletal support for DriverKit platform

Define the platform ID = 10, and simple mappings between platform ID & name.

Reviewed By: MaskRay, cishida

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

Test commit

Test commit access to the LLVM repository.

Fix warning caused by ReductionTreePass class

Explicitly declare ReductionTreeBase base class in ReductionTreePass copy constructor.

Reviewed By: mehdi_amini

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

[llvm-libtool-darwin] Add support for -l and -L

Add support for passing in libraries via `-l` and `-L` options to
`llvm-libtool-darwin`.

Reviewed by jhenderson, smeenai

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

[DFSan] Don't unmap during dfsan_flush().

Unmapping and remapping is dangerous since another thread could touch
the shadow memory while it is unmapped.  But there is really no need to
unmap anyway, since mmap(MAP_FIXED) will happily clobber the existing
mapping with zeroes.  This is thread-safe since the mmap() is done under
the same kernel lock as page faults are done.

Reviewed By: vitalybuka

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

[examples][cmake] build fix for examples with BUILD_SHARED_LIBS=on

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

[mlir] build fix for gcc-5

It appears in this case that an implicit cast from StringRef to std::string
doesn't happen.  Fixed with an explicit cast.

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

[mlir] Make mlir_check_link_libraries() work with interface libraries

This changes mlir_check_link_libraries() to work with interface libraries.
These don't have the LINK_LIBRARIES property.

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

[llvm-libtool-darwin] Support universal outputs

Add support for producing universal binaries containing archives when
`llvm-libtool-darwin` is given inputs of multiple architectures.

Reviewed by jhenderson, smeenai

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

[clang-tools-extra] Added missing comma

The new diagnostic tool (D85545) caught a missing comma, adding one to fix the warning.

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

Remove unnecessary HEADER_DIRS in lib/InterfaceStub/CMakeLists.txt

This change removes unnecessary HEADER_DIRS from //llvm/lib/
InterfaceStub/CMakeLists.txt file.

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

TableGen/GlobalISel: Partially handle immAllOnesV/immAllZerosV

These should really match either G_BUILD_VECTOR or
G_BUILD_VECTOR_TRUNC, but there doesn't seem to be an existing
mechanism for matching alternative opcodes. There is GIM_SwitchOpcode,
but it seems to assume it's oly only used for matcher optimization.

I could also omit any opcode check and rely on the matcher directly
checking the opcode, but the table optimizer currently assumes there
has to be an opcode check.

Also doesn't try to handle undef elements like the DAG version.

[X86][SSE] Fold HOP(SHUFFLE(X),SHUFFLE(Y)) --> SHUFFLE(HOP(X,Y))

This is beginning to look like a canonicalization stage that could be performed as part of shuffle combining

Another step towards PR41813

Recommit of rG9bd97d036398 with fixed offset adjustments

AMDGPU/GlobalISel: Match andn2/orn2 for more types

Unfortunately this ends up not working as expected on targets with
16-bit operations due to AMDGPUCodeGenPrepare's promotion of uniform
16-bit ops to i32.

The vector case annoyingly requires switching the checked opcode,
since constants for vectors aren't directly handled.

I also need to think more carefully about whether this is valid for i1.

Add python enumerators for SBTypeEnumMemberList, and some tests for this API.

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

Minor build fix (pointer must be dereferenced with `->`)

[TSan][libdispatch] Add interceptors for dispatch_async_and_wait()

Add interceptors for `dispatch_async_and_wait[_f]()` which was added in
macOS 10.14.  This pair of functions is similar to `dispatch_sync()`,
but does not force a context switch of the queue onto the caller thread
when the queue is active (and hence is more efficient).  For TSan, we
can apply the same semantics as for `dispatch_sync()`.

From the header docs:
> Differences with dispatch_sync()
>
> When the runtime has brought up a thread to invoke the asynchronous
> workitems already submitted to the specified queue, that servicing
> thread will also be used to execute synchronous work submitted to the
> queue with dispatch_async_and_wait().
>
> However, if the runtime has not brought up a thread to service the
> specified queue (because it has no workitems enqueued, or only
> synchronous workitems), then dispatch_async_and_wait() will invoke the
> workitem on the calling thread, similar to the behaviour of functions
> in the dispatch_sync family.

Additional context:
> The guidance is to use `dispatch_async_and_wait()` instead of
> `dispatch_sync()` when it is necessary to mix async and sync calls on
> the same queue. `dispatch_async_and_wait()` does not guarantee
> execution on the caller thread which allows to reduce context switches
> when the target queue is active.
> https://gist.github.com/tclementdev/6af616354912b0347cdf6db159c37057

rdar://35757961

Reviewed By: kubamracek

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

Remove dependency from lib/CAPI/IR/IR.cpp on registerAllDialects() (build fix)

This library does not depend on all the dialects, conceptually. This is
changing the recently introduced `mlirContextLoadAllDialects()` function
to not call `registerAllDialects()` itself, which aligns it better with
the C++ code anyway (and this is deprecated and will be removed soon).

[ORC] Build LLJITWithChildProcess example only on UNIX host systems

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

[lldb] Remove Python 2 fallback and only support Python 3

This removes the fallback to Python 2 and makes Python 3 the only
supported configuration. This is the first step to fully migrate to
Python 3 over the coming releases as discussed on the mailing list.

http://lists.llvm.org/pipermail/lldb-dev/2020-August/016388.html

As a reminder, for the current release the test suite and the generated
bindings should remain compatible with Python 2.

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

[NFC] Silence variables unused in release builds

[lldb] Use file to synchronize TestDeepBundle and TestBundleWithDotInFilename

Currently these two tests use an arbitrary wait of 5 seconds for the
inferior to finish setting up. When the test machine is under heavy load
this sometimes is insufficient leading to spurious test failures. This
patch adds synchronization trough a token on the file system. In
addition to making the test more reliable it also makes it much faster
because we no longer have to wait the full 5 seconds if the setup was
completed faster than that.

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

[Statepoints] FixupStatepoint: properly set isKill on spilled register.

When spilling statepoint meta arg register it is incorrect to blindly
mark it as killed - it may be used in non-meta args (e.g., as call
parameter).

Revert "[NFC][StackSafety] Move out sort from the loop"

This reverts commit 0426e28419799c35cf52fe3d773c5bab9928c699 due to ASan
buildbot failure.