[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.

[ARM][test] Add more tests of two-part immediates

The ARM backend breaks some specific immediates to two parts
in binary operations. And this patch adds more tests
for that.

Reviewed By: samparker

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

[DFSan] Fix parameters to strtoull wrapper.

base and nptr_label were swapped, which meant we were passing nptr's
shadow as the base to the operation.  Usually, the shadow is 0, which
causes strtoull to guess the correct base from the string prefix (e.g.,
0x means base-16 and 0 means base-8), hiding this bug.  Adjust the test
case to expose the bug.

Reviewed By: vitalybuka

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

[DemandedBits] Add addition test case from D72423

[OpenMP][OMPIRBuilder] Use the source (=directory + filename) for locations

Reviewed By: lebedev.ri

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

[OpenMP][NFC] Update test check lines with new script version

[Orc] Fix werror for unused variable in noasserts build

[Statepoints] Spill GC Ptr regs in FixupStatepoints.

Extend FixupStatepointCallerSaved pass with ability to spill
statepoint GC pointer arguments (optionally allowing them on CSRs).
Special handling is required for invoke statepoints, because at MI
level single landing pad may be shared by multiple statepoints, so
we must ensure we spill landing pad's live-ins into the same stack
slots.

Full statepoint refactoring change set is available at D81603.

Reviewed By: skatkov

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

[VE] Remove obsolete I8/I16 register classes

Remove I8/I16 register classes which are prepared to implement previously
to implement VE ABI.  However, it is possible to implement VE ABI correctly
without them.  Therefore, removing them now.

Reviewed By: simoll

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

[lldb] Make packetlog_get_dylib_info returns the last full response

In sanitized builds the last packet this function finds for the
TestMacCatalyst and TestPlatformSimulator tests is for the asan runtime.

```
 <  69> send packet: $jGetLoadedDynamicLibrariesInfos:{"solib_addresses":[4296048640]}]#3a <
 715> read packet: ${"images":[{"load_address":4296048640,"mod_date":0,"pathname":
 "/Users/buildslave/jenkins/workspace/lldb-cmake-sanitized/host-compiler/lib/clang/12.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib",
 "uuid":"8E38A2CD-753F-3E0F-8EB0-F4BD5788A5CA",
 "min_version_os_name":"macosx","min_version_os_sdk":"10.9",
 "mach_header":{"magic":4277009103,"cputype":16777223,"cpusubtype":3,"filetype":6,
 "flags":43090053}],"segments":[{"name":"__TEXT","vmaddr":0,"vmsize":565248,"fileoff":0,
 "filesize":565248,"maxprot":5}],{"name":"__DATA","vmaddr":565248,"vmsize":13152256,"fileoff":565248,
 "filesize":20480,"maxprot":3}],{"name":"__LINKEDIT","vmaddr":13717504,"vmsize":438272,"fileoff":585728,
 "filesize":435008,"maxprot":1}]]}]]}]#00
```

This just fetches the last package which has fetch_all_solibs and we know
it will contain the image of our test executable to get the tests running again.

[libc] [obvious] Fix typographical error.

[Attributor] Implement AAPotentialValues

This patch provides an implementation of `AAPotentialValues`.

Reviewed By: jdoerfert

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

[NFC][StackSafety] Change map key comparison

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

[lldb] Use SBProcess::Continue instead of 'run' command in TestTargetAPI.py

This test is flaky on Green Dragon as it often fails when the process state
is "Invalid" in the assert:
    self.assertEqual(process.GetState(), lldb.eStateExited)
It seems this is related to just doing "run" which apparently invalidates
the Target's process in case it's still running and needs to be restarted.
Just doing 'continue' on the process (and ignoring the error in case it already
finished) prevents that and makes this consistently pass for me.

Just pushing this out to get Green Dragon back online.

[lldb] Check Decl kind when completing -flimit-debug-info types

The search for the complete class definition can also produce entries
which are not of the expected type. This can happen for instance when
there is a function with the same name as the class we're looking up
(which means that the class needs to be disambiguated with the
struct/class tag in most contexts).

Previously we were just picking the first Decl that the lookup returned,
which later caused crashes or assertion failures if it was not of the
correct type. This patch changes that to search for an entry of the
correct type.

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

[lldb] Fix py3 incompatibility in gdbremote_testcase.py

This didn't cause test failures since this variable is only used during
connection shutdown.

[ORC] Fix missing include in OrcRemoteTargetClient.h

[lldb] Deduplicate copy-pasted TypeSystemMap::GetTypeSystemForLanguage

There are two implementations for `TypeSystemMap::GetTypeSystemForLanguage`
which are both identical beside one taking a `Module` and one taking a `Target`
(and then passing that argument to the `TypeSystem::CreateInstance` function).

This merges both implementations into one function with a lambda that wraps the
different calls to `TypeSystem::CreateInstance`.

Reviewed By: #lldb, JDevlieghere

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

[ORC][NFC] Fix a header comment

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.

[lldb] Display autosuggestion part in gray if there is one possible suggestion

This is relanding D81001. The patch originally failed as on newer editline
versions it seems CC_REFRESH will move the cursor to the start of the line via
\r and then back to the original position. On older editline versions like
the one used by default on macOS, CC_REFRESH doesn't move the cursor at all.
As the patch changed the way we handle tab completion (previously we did
REDISPLAY but now we're doing CC_REFRESH), this caused a few completion tests
to receive this unexpected cursor movement in the output stream.
This patch updates those tests to also accept output that contains the specific
cursor movement commands (\r and then \x1b[XC). lldbpexpect.py received an
utility method for generating the cursor movement escape sequence.

Original summary:

I implemented autosuggestion if there is one possible suggestion.
I set the keybinds for every character. When a character is typed, Editline::TypedCharacter is called.
Then, autosuggestion part is displayed in gray, and you can actually input by typing C-k.
Editline::Autosuggest is a function for finding completion, and it is like Editline::TabCommand now, but I will add more features to it.

Testing does not work well in my environment, so I can't confirm that it goes well, sorry. I am dealing with it now.

Reviewed By: teemperor, JDevlieghere, #lldb

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

[ORC][NFC] Refactor loop to determine name of init symbol in IRMaterializationUnit

This loop caused me a little headache once, because I didn't see the assigned variable is a member. The refactored version appears more readable to me.

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

[ORC] In LLLazyJIT provide public access to the CompileOnDemandLayer

This is analog to how LLJIT provides public access to all its layers.

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

[ORC] Add JITLink-compatible remote memory-manager and LLJITWithChildProcess example

This adds RemoteJITLinkMemoryManager is a new subclass of OrcRemoteTargetClient. It implements jitlink::JITLinkMemoryManager and targets the OrcRemoteTargetRPCAPI.

Behavior should be very similar to RemoteRTDyldMemoryManager. The essential differnce with JITLink is that allocations work in isolation from its memory manager. Thus, the RemoteJITLinkMemoryManager might be seen as "JITLink allocation factory".

RPCMMAlloc is another subclass of OrcRemoteTargetClient and implements the actual functionality. It allocates working memory on the host and target memory on the remote target. Upon finalization working memory is copied over to the tagrte address space. Finalization can be asynchronous for JITLink allocations, but I don't see that it makes a difference here.

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

[mlir] do not emit bitcasts between structs in StandardToLLVM

The convresion of memref cast operaitons from the Standard dialect to the LLVM
dialect has been emitting bitcasts from a struct type to itself. Beyond being
useless, such casts are invalid as bitcast does not operate on aggregate types.
This kept working by accident because LLVM IR bitcast construction API skips
the construction if types are equal before it verifies that the types are
acceptable in a bitcast. Do not emit such bitcasts, the memref cast that only
adds/erases size information is in fact a noop on the current descriptor as it
always contains dynamic values for all sizes.

Reviewed By: pifon2a

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

[mlir] Mention mandatory RFC process for changes in Standard dialect

We have been asking for this systematically, mention it in the documentation.

Reviewed By: mehdi_amini

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

[NFC][ARM] Port MaybeCall into ARMTTImpl method

Renamed to maybeLoweredToCall.

[MLIR][Shape] Add custom assembly format for `shape.any`

Add custom assembly format for `shape.any` with variadic operands.

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

[lldb/Utility] Simplify Scalar::PromoteToMaxType

The function had very complicated signature, because it was trying to
avoid making unnecessary copies of the Scalar object. However, this
class is not hot enough to worry about these kinds of optimizations. My
making copies unconditionally, we can simplify the function and all of
its call sites.

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

[clangd] Clarify comments regarding gRPC linking

[clangd] Fix find_program() result check when searching for gRPC

`find_program(<VAR> ...)` sets <VAR> to <VAR>-NOTFOUND if nothing was found.
So we need to compare <VAR> with "<VAR>-NOTFOUND" or just use `if([NOT] <VAR>)`, because `if(<VAR>)` is false if `<VAR>` ends in the suffix -NOTFOUND.

Reviewed By: kbobyrev

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

[OpenMP] Fix releasing of stack memory

Starting with 787eb0c637b I got spurious segmentation faults for some testcases. I could nail it down to `brel` trying to release the "memory" of the node allocated on the stack of __kmpc_omp_wait_deps. With this patch, you will see the assertion triggering for some of the tests in the test suite.

My proposed solution for the issue is to just patch __kmpc_omp_wait_deps:
```
  __kmp_init_node(&node);
-  node.dn.on_stack = 1;
+  // the stack owns the node
+  __kmp_node_ref(&node);
```

What do you think?

Reviewed By: AndreyChurbanov

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

[clangd] Warn developers when trying to link system-installed gRPC statically

Reviewed By: sammccall

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

[NFC][StackSafety] Dedup callees

Remove spurious empty line at the beginning of source file (NFC)

Fix BufferPlacement Pass to derive from the TableGen generated parent class (NFC)

[CGAtomic] Mark atomic libcall functions `nounwind`

These functions won't ever unwind. This is useful for MemorySanitizer
as it simplifies handling __atomic_load in particular.

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

[gn build] Port 2e4a20fd706

[SyntaxTree] Split `TreeTestBase` into header and source

* Switch to using directive on source files.
* Remove unused `SyntaxTreeTest::addFile`

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

[lldb] Fix a crash when tab-completion an empty line in a function with only one local variable

When LLDB sees only one possible completion for an input, it will add a trailing
space to the completion to signal that to the user. If the current argument is
quoted, that also means LLDB needs to add the trailing quote to finish the
current argument first.

In case the user is in a function with only one local variable and is currently
editing an empty line in the multiline expression editor, then we are in the
unique situation where we can have a unique completion for an empty input line.
(In a normal LLDB session this would never occur as empty input would just list
all the possible commands).

In this special situation our check if the current argument needs to receive a
trailing quote will crash LLDB as there is no current argument and the
completion code just unconditionally tries to access the current argument. This
just adds the missing check if we even have a current argument before we check
if we need to add a terminating quote character.

Reviewed By: labath

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

[AMDGPU] Enable .rodata for amdpal os

PAL recently got support for multiple ELF sections and relocations,
therefore we can now use .rodata sections instead of forcing constants
into .text.

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

[SVE] Fix bug in SVEIntrinsicOpts::optimizePTest

The code wasn't taking into account that the two operands
passed to ptest could be identical and was trying to erase
them twice.

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

[NFCI][SimpleLoopUnswitch] Adjust CostKind query

When getUserCost was transitioned to use an explicit CostKind,
TCK_CodeSize was used even though the original kind was implicitly
SizeAndLatency so restore this behaviour. We now only query for
CodeSize when optimising for minsize.

I expect this to not change anything as, I think all, targets will
currently return the same value for CodeSize and SizeLatency. Indeed
I see no changes in the test suite for Arm, AArch64 and X86.

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

[DebugInfo] Avoid an infinite loop with a truncated pre-v5 .debug_str_offsets.dwo.

dumpStringOffsetsSection() expects the size of a contribution to be
correctly aligned. The patch adds the corresponding verifications for
pre-v5 cases.

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

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

This reverts commit ab9fc8bae805c785066779e76e7846aabad5609e.

Incorrect transformation if the result is used.
Causes breakages, e.g.
http://green.lab.llvm.org/green/job/test-suite-verify-machineinstrs-x86_64-O3/8193/

[NFC] Remove unused function.

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

[mlir] [VectorOps] Canonicalization of 1-D memory operations

Masked loading/storing in various forms can be optimized
into simpler memory operations when the mask is all true
or all false. Note that the backend does similar optimizations
but doing this early may expose more opportunities for further
optimizations. This further prepares progressively lowering
transfer read and write into 1-D memory operations.

Reviewed By: ThomasRaoux

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

[WebAssembly] Add missing lit.local.cfg

hwasan: Emit the globals note even when globals are uninstrumented.

This lets us support the scenario where a binary is linked from a mix
of object files with both instrumented and non-instrumented globals.
This is likely to occur on Android where the decision of whether to use
instrumented globals is based on the API level, which is user-facing.

Previously, in this scenario, it was possible for the comdat from
one of the object files with non-instrumented globals to be selected,
and since this comdat did not contain the note it would mean that the
note would be missing in the linked binary and the globals' shadow
memory would be left uninitialized, leading to a tag mismatch failure
at runtime when accessing one of the instrumented globals.

It is harmless to include the note when targeting a runtime that does
not support instrumenting globals because it will just be ignored.

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

[NewPM][CodeGen] Add machine code verification callback

D83608 need this.

Reviewed By: aeubanks

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

[X86][ELF] Prefer lowering MC_GlobalAddress operands to .Lfoo$local for STV_DEFAULT only

This patch restricts the behaviour of referencing via .Lfoo$local
local aliases, introduced in https://reviews.llvm.org/D73230, to
STV_DEFAULT globals only.

Hidden symbols via --fvisiblity=hidden (https://gcc.gnu.org/wiki/Visibility)
is an important scenario.

Benefits:

- Improves the size of object files by using fewer STT_SECTION symbols.

- The code reads a bit better (it was not obvious to me without going
  back to the code reviews why the canBenefitFromLocalAlias function
  currently doesn't consider visibility).

- There is also a side benefit in restoring the effectiveness of the
  --wrap linker option and making the behavior of --wrap consistent
  between LTO and normal builds for references within a translation-unit.
  Note: this --wrap behavior (which is specific to LLD) should not be
  considered reliable. See comments on https://reviews.llvm.org/D73230
  for more.

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

[ConstProp] Handle insertelement constants

Previously ConstantFoldExtractElementInstruction() would only work with
insertelement instructions, not contants. This properly handles
insertelement constants as well.

Reviewed By: efriedma

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

[DebugInfo] Add -fuse-ctor-homing cc1 flag so we can turn on constructor homing only if limited debug info is already on.

This adds a cc1 flag to enable constructor homing but doesn't turn on debug
info if it wasn't enabled already (which is what using
-debug-info-kind=constructor does). This will be used for testing, and won't
be needed anymore once ctor homing is used as default / merged into =limited.

Bug to enable ctor homing: https://bugs.llvm.org/show_bug.cgi?id=46537

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

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

Solves 46489

[NFC] Remove unused variables.

These were no longer needed following
96855125e77044b1a5d3c7f0ae90ea3a5cb035c0.

Reviewed By: rupprecht

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

Revert "[ARM] Fix IT block generation after Thumb2SizeReduce with -Oz"

This reverts commit 18279a54b5d3382874924d6a3c7775b7e22598dc as it is
causing some chromium android test problems.

[lldb] Improve diagnostics in lldb-repro when replay fails

 - Print the replay invocation.
 - Keep the reproducer around.
 - Return the "opposite" exit code so we don't have to rely on FileCheck
   to fail the test when the expected exit code is non-zero.

[AMDGPU] Fix FP/BP spills when MUBUF constant offset exceeded

If we need a scratch register for the spill don't use the same scratch
register that is being used for the MBUF offset.

Reviewed By: arsenm

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

[WebAssembly] Allow inlining functions with different features

Allow inlining only when the Callee has a subset of the Caller's
features. In principle, we should be able to inline regardless of any
features because WebAssembly supports features at module granularity,
not function granularity, but without this restriction it would be
possible for a module to "forget" about features if all the functions
that used them were inlined.

Requested in PR46812.

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