[MIPS] Fix useDeprecatedPositionallyEncodedOperands errors.

This is a follow-on to https://reviews.llvm.org/D134073.

The number of MIPS16 changes here is a bit surprising. Many of the
fields with mismatched names were NOT previously choosing the correct
argument positionally, but instead doing something completely wrong
(e.g. it would encode a register where an immediate was expected).

But, machine-code generation for MIPS16 has never actually functioned.
It's also fully untested, thus, the MIPS16 changes, despite changing
behavior, breaks (and fixes) zero tests. This change does not fix
MIPS16 output, but it ought to be at least incrementally less broken.

Outside MIPS16, I believe the only functional change is to the 'ginvi'
instruction: it was previously encoding garbage into a field which was
specified to be '00'. Fortunately, it was covered by tests -- and the
tests were testing the incorrect behavior. So, fixed.

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

[Sparc] Fix useDeprecatedPositionallyEncodedOperands errors.

This is a follow-on to https://reviews.llvm.org/D134073.

It renames a few fields to have consistent names, as well as renaming
operands to match the field names.

Behavior is unchanged by this cleanup. (The only generated code change
is for the disassembler for LDSTUB/LDSTUBA, but in both old and new
versions, it fails to add enough operands, and thus triggers a runtime
abort. I will address that bug in a future commit.)

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

Update "Writing a Backend" doc to use named operand matching.

This brings it in line with recommended practice after the
introduction of sub-operand naming in a538d1f13a13, and the
deprecation of positional argument matching in 5351878ba196.

[InstCombine] add tests for demanded bits of sub; NFC

[SDAG] avoid vector extract/insert around binop

scalar-to-vector (scalar binop (extractelt V, Idx), C) --> shuffle (vector binop V, C'), {Idx, -1, -1...}

We generally try to avoid ad-hoc vectorization in SDAG,
but the motivating case from issue #39482 escapes our
normal vectorization folds in IR. It seems like it should
always be a win to transform this pattern in cases where
we have the same vector type for input and output and the
target supports the vector operation. That avoids
transfers from vector to scalar and back.

In the x86 shift examples, we create the scalar-to-vector
node during legalization. I'm not sure if there's a more
general way to create the pattern for testing. (If so, I
could add tests for other targets.)

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

ConstantFold: Reduce code duplication for checking commuted compare

[Driver] Avoid unsafe Twine local variable after D136707

Add tests for C11 DRs and update the status page

This gets a start on testing how we're doing for C11 DRs

[NFC] Introduce range based singleton searches for loop queries.

Summary:
Several loop queries look for a singleton by finding all instances and then
returning whether there is 1 instance or not. This can be improved by
stopping the search after 2 have been found. Introduce generic range
based singleton searches that stop after finding a second value
and use them for these loop queries.

There is no intended functional change other than improved compile-time
efficiency.

Author: Jamie Schmeiser <schmeise@ca.ibm.com>
Reviewed By: Meinersbur (Michael Kruse)
Differential Revision: https://reviews.llvm.org/D136261

[clang][Toolchains][Gnu] pass -gdwarf-* through to assembler

We've been working around this for a long time in the Linux kernel; we
bend over backwards to continue to support CC=clang (w/
-fno-integrated-as) for architectures where clang can't yet be used to
assemble the kernel's assembler sources. Supporting debug info for the
combination of CC=clang w/ GNU binutils as "GAS" has been painful.

Fix this in clang so that we can work towards dropping complexity in the
Linux kernel's build system, Kbuild, for supporting this combination of
tools.

GAS added support for -gdwarf-{3|4|5} in 2020 2.35 release via
commit 31bf18645d98 ("Add support for --dwarf-[3|4|5] to assembler command line.")

Refactor code to share logic between integrated-as and non-integrated-as
for determining the implicit default.  This change will now always
explicitly pass a -gdwarf-* flag to the GNU assembler when -g is
specified.

Reviewed By: MaskRay

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

[OpenMP][FIX] Do not add custom state machine eagerly in LTO runs

If we run LTO optimization we migth end up introducing a custom state machine
and later transforming the region into SPMD. This is a problem. While a follow
up will introduce a check for the SPMD conversion, this already prevents the
eager custom state machine generation. Only if the kernel init function is
defined, rather then declared, we will emit a custom state machine. SPMD-zation
can happen eagerly though. Tests are adjusted via a weak definition. The LTO
test was added to verify this works as expected.

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

[lldb] Fix a -Wdeprecated-declarations warning

Fixes:

    ../../lldb/source/Symbol/LocateSymbolFileMacOSX.cpp:633:26:
        warning: 'CFPropertyListCreateFromXMLData' is deprecated:
                 first deprecated in macOS 10.10 -
                 Use CFPropertyListCreateWithData instead.
                 [-Wdeprecated-declarations]
        (CFDictionaryRef)::CFPropertyListCreateFromXMLData(
                           ^

Hopefully no behavior change.

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

clang: Add a cmake toggle to disable libclang's libxml2 dependency

By default, libclang will still depend on libxml2 according to
LLVM_ENABLE_LIBXML2, but with this it's possible to make libclang
not depend on libxml2 even though LLVM does.

The motivation is that libclang uses a bigger API surface of libxml2
than LLVM, and we're statically linking a very minimal build of
libxml2 in our LLVM/clang distribution.

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

[Flang] Add MLIRComplexToLLVM, MLIRComplexToStandard in link libs

Reviewed By: vzakhari

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

Reland "[PGO] Make emitted symbols hidden"

This was reverted because it was breaking when targeting Darwin which
tried to export these symbols which are now hidden. It should be safe
to just stop attempting to export these symbols in the clang driver,
though Apple folks will need to change their TAPI allow list described
in the commit where these symbols were originally exported
https://github.com/llvm/llvm-project/commit/f5380185623be243ba0f1b18d4bd594ac5cc7163

Then reverted again because it broke tests on MacOS, they should be
fixed now.

Bug: https://github.com/llvm/llvm-project/issues/58265

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

[RISCV] add svinval extension

1. Add the svinval extension support
2. Add the svinval Predicates for its instruction

Note: the svinval instructions defined in https://reviews.llvm.org/D117654

Reviewed By: reames

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

[RISCV] Use vslide1down for i64 insertelt on RV32.

Instead of using vslide1up, use vslide1down and build the other
direction. This avoids the overlap constraint early clobber of
vslide1up.

Reviewed By: reames

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

[AMDGPU][test] precommiting tests for D136663

More tests for si-peephole-sdwa pass

[FuncSpec] Add a testcase for the treatment of constant and unused arguments

Increase test coverage - check that functions are not specialised on
constant or unused arguments.

Reviewed By: SjoerdMeijer

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

[mlir][sparse] Extend sparse_tensor.push_back to allow push_back a value n times.

Reviewed By: aartbik, Peiming

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

[TableGen] Add log bang operator

This patch adds base 2 logarithm that returns integer result. I initially wanted to name it `!log2`,
but numbers are not permitted in the name. The documentation makes sure to clarify that it is
base 2 since it is not explicit in the operator name.

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

[libc++][test] Don't use _LIBCPP macros.

This was discovered by @ldionne.

Reviewed By: #libc, ldionne

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

[clang][dataflow] Remove unused 'Analysis' field from 'TerminatorVisitor'

This is to silence the warning: private field 'Analysis' is not used

[analyzer] Initialize regions returned by CXXNew to undefined

Discourse mail:
https://discourse.llvm.org/t/analyzer-why-do-we-suck-at-modeling-c-dynamic-memory/65667

malloc() returns a piece of uninitialized dynamic memory. We were (almost)
always able to model this behaviour. Its C++ counterpart, operator new is a
lot more complex, because it allows for initialization, the most complicated of which is the usage of constructors.

We gradually became better in modeling constructors, but for some reason, most
likely for reasons lost in history, we never actually modeled the case when the
memory returned by operator new was just simply uninitialized. This patch
(attempts) to fix this tiny little error.

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

[SDAG] add helper for opcodes that are not speculatable

This is not quite NFC because one of the users should
now avoid the DIVREM opcodes too, but I'm not sure
how to test that.

I used the same name as an analysis function in IR
in case we want to expand this to include other
operations.

Another potential use is proposed in D136713.

[x86] add tests for extract + insert of vector shift amount; NFC

[Docs][NFC] Update my office hour information

[mlir][spirv] Flip createConvertGPUToSPIRVPass mapMemorySpace default

Some down-stream libraries only have access to CAPI, setting
default value of mapMemorySpace to true will help them convert IR
to SPIR-V.

Reviewed By: antiagainst

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

Add a testcase for D136192.

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

[analyzer][StdLibraryFunctionsChecker] Add NoteTags for applied arg
constraints

In this patch I add a new NoteTag for each applied argument constraint.
This way, any other checker that reports a bug - where the applied
constraint is relevant - will display the corresponding note. With this
change we provide more information for the users to understand some
bug reports easier.

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

Reviewed By: NoQ

[clang][ASTImporter] Remove use of ParentMapContext.

Function 'isAncestorDeclContextOf' was using 'ParentMapContext' for
looking up parent of statement nodes. There may be cases (bugs?) with
ParentMapContext when parents of specific statements are not found.
This leads to 'ASTImporter' infinite import loops when function
'hasAutoReturnTypeDeclaredInside' returns false incorrectly.
A real case was found but could not be reproduced with test code.
Use of 'ParentMapContext' is now removed and changed to a more safe
(currently) method by searching for declarations in statements
and find parent of these declarations. The new code was tested on
a number of projects and no related crash was found.

Reviewed By: martong

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

[Lex] Stop allocating/deallocating MacroInfo on a linked list. NFC

This list was originally used for to make sure MacroInfo's clever memory
management got called (1f1e4bdbf7815c), but that was
simplified in 73a29662b9bf640a and 1f1e4bdbf7815c, and there's nothing left.

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

[UpdateTestChecks] Sync flags in update_mir_test_checks.py with MIFlags

Some instructions are not matched by update_mir_test_checks.py because MIFlags and
regex in the script are not synchronized.

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

[gn build] Port bb72d0dde29e

[clang][dataflow] Implement transferBranch

This patch introduces `transferBranch`, which Applies the analysis
transfer function for a given edge from a CFG block of a conditional
statement.

RFC:
https://discourse.llvm.org/t/rfc-clang-dataflow-signanalysis-edgetransfer-branchtransfer/65220

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

[gn build] Port 93ce23adb548

[clang][dataflow] Add initial sign analysis

This patch adds an initial implementation for sign analysis, with the
following lattice (T: top, N: negative, Z: zero, P: positive, B: bottom):
  T
/ | \
N Z P
\ | /
  B
The lattice is implemented with `BoolValue` properties attached to other
`Value`s.

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

Revert "[FuncSpec] Fix specialisation based on literals"

This reverts commit a8b0f580170089fcd555ade5565ceff0ec60f609 because
of "reverse-iteration" buildbot failure.

Revert "[FuncSpec][NFC] Refactor finding specialisation opportunities"

This reverts commit a8853924bd3c50deebfbf993c037257ccf9805f4 due to dependency
on a8b0f5801700

[UpdateTestChecks] Precommit test for D136170

[flang] Use mlir complex dialect for supported operations

This patch lowers the complex operations supported by the MLIR complex
dialect to those operations rather than libm. When the math runtime flag
is set to precise, libm lowering is used instead.

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

[LLDB] Correct env vars for Android port selection

These should have "LOCAL" in them.

First added in 1e210abf9925ad08fb7c79894b4ec5ef8f0ef173.

[flang] Use tdesc on fir.embox in code generation

For polymoprhic entities, the type descriptor is dynamic. The tdesc
operand on fir.embox is meant to propagate the dynamic type when
embox a polymorphic entity.
This patch makes use of this operand in code generation and update
the created descriptor accordingly.

Reviewed By: jeanPerier

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

[Lex] Bring back the magic number 50 in updateConsecutiveMacroArgTokens.

This patch is a reland of 74e4f778cf16cbf7163b5c6de6027a43f5e9169f and
f83347b0bedb22ea676861c8e4e2ed9c31371ade with the removed 50 trick back.

The magic number 50 was removed in D134942, as a behavior change for
performance reason.

While it reduces the number of SLocEntry, it increases the usage of
SourceLocation address space usage, which is critical for compiling
large TU.

This fixes a regression caused in D134942 -- clang failed to compile one of
our internal files, complaining the file is too large to process because clang
runs out of source location space (we spend 40% more address space!)

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

Take memset_inline into account in analyzeLoadFromClobberingMemInst

This appeared in https://reviews.llvm.org/D126903#3884061

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

[analyzer] Fix assertion failure with conflicting prototype calls

It turns out we can reach the `Init.castAs<nonlock::CompoundVal>()`
expression with other kinds of SVals. Such as by `nonloc::ConcreteInt`
in this example: https://godbolt.org/z/s4fdxrcs9

```lang=C++
int buffer[10];
void b();
void top() {
  b(&buffer);
}
void b(int *c) {
  *c = 42; // would crash
}
```
In this example, we try to store `42` to the `Elem{buffer, 0}`.

This situation can appear if the CallExpr refers to a function
declaration without prototype. In such cases, the engine will pick the
redecl of the referred function decl which has function body, hence has
a function prototype.

This weird situation will have an interesting effect to the AST, such as
the argument at the callsite will miss a cast, which would cast the
`int (*)[10]` expression into `int *`, which means that when we evaluate
the `*c = 42` expression, we want to bind `42` to an array, causing the
crash.

Look at the AST of the callsite with and without the function prototype:
https://godbolt.org/z/Gncebcbdb
The only difference is that without the proper function prototype, we
will not have the `ImplicitCastExpr` `BitCasting` from `int (*)[10]`
to `int *` to match the expected type of the parameter declaration.

In this patch, I'm proposing to emit a cast in the mentioned edge-case,
to bind the argument value of the expected type to the parameter.

I'm only proposing this if the runtime definition has exactly the same
number of parameters as the callsite feeds it by arguments.
If that's not the case, I believe, we are better off by binding `Unknown`
to those parameters.

Reviewed By: martong

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

[FuncSpec][NFC] Refactor finding specialisation opportunities

This patch reorders the traversal of function call sites and function
formal parameters to:

* do various argument feasibility checks (`isArgumentInteresting` ) only once per argument, i.e. doing N-args checks instead of N-calls x N-args checks.

* do hash table lookups only once per call site, i.e. N-calls lookups/inserts instead of N-call x N-args lookups/inserts.

Reviewed By: ChuanqiXu, labrinea

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

[FuncSpec] Compute specialisation gain even when forcing specialisation

When rewriting the call sites to call the new specialised functions, a
single call site can be matched by two different specialisations - a
"less specialised" version of the function and a "more specialised"
version of the function, e.g.  for a function

    void f(int x, int y)

the call like `f(1, 2)` could be matched by either

    void f.1(int x /* int y == 2 */);

or

    void f.2(/* int x == 1, int y == 2 */);

The `FunctionSpecialisation` pass tries to match specialisation in the
order of decreasing gain, so "more specialised" functions are
preferred to "less specialised" functions. This breaks, however, when
using the flag `-force-function-specialization`, in which case the
cost/benefit analysis is not performed and all the specialisations are
equally preferable.

This patch makes the pass calculate specialisation gain and order the
specialisations accordingly even when `-force-function-specialization`
is used, under the assumption that this flag has purely debugging
purpose and it is reasonable to ignore the extra computing effort it
incurs.

Reviewed By: ChuanqiXu, labrinea

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

[FuncSpec] Fix specialisation based on literals

The `FunctionSpecialization` pass has support for specialising
functions, which are called with literal arguments. This functionality
is disabled by default and is enabled with the option
`-function-specialization-for-literal-constant` .  There are a few
issues with the implementation, though:

* even with the default, the pass will still specialise based on
   floating-point literals

* even when it's enabled, the pass will specialise only for the `i1`
    type (or `i2` if all of the possible 4 values occur, or `i3` if all
    of the possible 8 values occur, etc)

The reason for this is incorrect check of the lattice value of the
function formal parameter. The lattice value is `overdefined` when the
constant range of the possible arguments is the full set, and this is
the reason for the specialisation to trigger. However, if the set of
the possible arguments is not the full set, that must not prevent the
specialisation.

This patch changes the pass to NOT consider a formal parameter when
specialising a function if the lattice value for that parameter is:

* unknown or undef
* a constant
* a constant range with a single element

on the basis that specialisation is pointless for those cases.

Is also changes the criteria for picking up an actual argument to
specialise if the argument is:

* a LLVM IR constant
* has `constant` lattice value
 has `constantrange` lattice value with a single element.

Reviewed By: ChuanqiXu

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

[clangd] Hover: Only drop UsingDecl instead of BaseUsingDecl

Since https://reviews.llvm.org/D135506 it's sufficient to only drop UsingDecl here

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

[SelectionDAG] Clamp stack alignment for memset, memmove

memcpy has clamped dst stack alignment to NaturalStackAlignment if
hasStackRealignment is false. We should also clamp stack alignment
for memset and memmove. If we don't clamp, SelectionDAG may first
do tail call optimization which requires no stack realignment. Then
memmove, memset in same function may be lowered to load/store with
larger alignment leading to PEI emit stack realignment code which
is absolutely not correct.

Reviewed By: LuoYuanke

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

[mlir][llvm] Tighten LLVM dialect intrinsic type constraints.

The revision specifies more precise argument and result type
constraints for many of the llvm intrinsics. Additionally, add
tests to verify intrinsics with invalid arguments/result result
in a verification error.

Reviewed By: ftynse

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

Revert "[clang] Changes to produce sugared converted template arguments"

This reverts commit 11ce78940b4c6f44ae6ee5a6611d6c9b1bade1c2.

Revert "[clang] Perform sugared substitution of builtin templates"

This reverts commit e5d9e802e50dd55a326e31a0d562e5263b208f3b.

Revert "[clang] Implement sugared substitution changes to infrastructure"

This reverts commit c4c2a3c65684e062efcd101a957c6cae0a304a7a.

Revert "[clang] Instantiate NTTPs and template default arguments with sugar"

This reverts commit 2560c1266993af6e6c15900ce673c6db23132f8b.

Revert "[clang] Instantiate alias templates with sugar"

This reverts commit 4c44c91ad980304c5cca3792115349e68cfafd2b.

Revert "[clang] Instantiate concepts with sugared template arguments"

This reverts commit d0a6de59c78010118fea811514e03ed9f400215a.

[LLDB] Make remote-android local ports configurable

The local ports for `platform connect` and `attach` were always random, this allows the user to configure them.
This is useful for debugging a truly remote android (when the android in question is connected to a remote server).

There is a lengthier discussion on github - https://github.com/llvm/llvm-project/issues/58114

Reviewed By: clayborg

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

[GlobalISel] Add Predicates to GICombineRule

Small QoL change to allow Predicates to be used in GICombineRule.
Currently only one combine in the AMDGPU backend makes use of it.

The implementation is pretty simple to get started but of course we can expand this later on and optimize predicate checking better if needed.

Reviewed By: dsanders

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

[AMDGPU] Autogenerate llvm.amdgcn.fcmp.ll

Prep commit for adding GISel run lines to that test.

Reviewed By: arsenm

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

[clang][Interp][NFC] Simplify InterpFrame::describe

[clang][Interp][NFC] Assert we have a valid Record instance

[clang][Interp][NFC] Make InitMap final

[clang][Interp][NFC] Simplify generated code for references

Instead of getting a pointer to a pointer to a value, followed by
dereferencing once, leaving us with a pointer to a value, we can instead
just get the pointer to the value (the reference in question) directly.
This simplifies (and shrinks) the generated bytecode somewhat.

[clang][Interp] Fix InterpFrame::describe() for This pointers

Since we pass this via the stack, we need to account for it when
desribing the stack frame (parameters). This fixes a previously
commented-out test case.

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

[clang][Interp] Implement for loops

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

[clang][driver] Remove dynamic gcc-toolset/devtoolset logic

This breaks when the newest available devtoolset directory is not a
complete toolset: https://github.com/llvm/llvm-project/issues/57843

Remove this again in favor or just adding the two new directories for
devtoolset/gcc-toolset 12.

This reverts commit 35aaf548237a4f213ba9d95de53b33c5ce1eadce.
This reverts commit 9f97720268911abae2ad9d90e270358db234a1c1.

Fixes https://github.com/llvm/llvm-project/issues/57843

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

[flang][CMake] Remove BACKEND_PACKAGE_STRING

Similar to D136660

[BOLT][TEST] Add pseudoprobe-decoding tests

Upstream internal tests, leveraging llvm-profgen binaries.

Reviewed By: hoy

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

[NFC] fix a wrong name change during rebase

[llvm-profgen] Do not cache the frame location stack during computing inlined context size

In `computeInlinedContextSizeForRange`, the offset of range is only used one time, there is no need to cache the frame location stack.
Measured on one internal service binary, this can save 2GB memory usage and reduce a small run time (avoid one hash search).

Reviewed By: hoy, wenlei

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

[OpenMP] kmp_affinity.h: add missing #else

When detect __NR_sched_getaffinity. the last #else is missing,
which make the last platform MIPS64 failed to build with an error:
   "Unknown or unsupported architecture"

Reviewed By: MaskRay

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

[sanitizer] Update struct_kernel_stat_sz for mips32 and mipsn32

On mips32 _LARGEFILE_SOURCE and _FILE_OFFSET_BITS == 64 is used (compiler-rt/cmake/base-config-ix.cmake),
thus the correct struct_kernel_stat_sz should be 160 instead of 144.

This value is also updated for N32, since we will use
_LARGEFILE_SOURCE and _FILE_OFFSET_BITS == 64 in future.

Fix https://github.com/llvm/llvm-project/issues/55499

Reviewed By: MaskRay

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

[GlobalISel][AArch64] Fix miscompile caused by wrong G_ZEXT selection in GISel

The miscompile case's G_ZEXT has a G_FREEZE source.  Similar to D127154, this patch removed isDef32, relying on the AArch64MIPeephole optimizer to remove redundant SUBREG_TO_REG nodes also in GISel.

Fix #58431

Reviewed By: paquette

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

[lldb-vscode] Send Statistics Dump in terminated event

This patch will gather debug info & breakpoint info from the statistics dump and send to DAP in terminated event.

We will return full contents of statistics dump (`SBTarget.GetStatistics()`) as a JSON string. So that every time a new field being added, we will be able to capture them from DAP log without changing lldb-vscode.

All the info above will be append to `statistics` field in the terminated event

Test Plan

Debugged a simple hello world program from VSCode. Exit debug session in two ways: 1) run to program exit; 2) user initiated debug session end (quit debugging before program exit).
Check DAP log and see both debug sessions have statistics returned in terminated event.

Here's an example when debugging the test program:

```
{"event":"terminated","seq":0,"statistics":"{\"memory\":{\"strings\":{\"bytesTotal\":1851392,\"bytesUnused\":905933,\"bytesUsed\":945459}},\"modules\":[{\"debugInfoByteSize\":0,\"debugInfoEnabled\":false,\"debugInfoIndexLoadedFromCache\":false,\"debugInfoIndexSavedToCache\":false,\"debugInfoIndexTime\":0,\"debugInfoParseTime\":0,\"identifier\":93901655961472,\"path\":\"/data/users/wanyi/llvm-sand/build/Debug/fbcode-x86_64/toolchain/lldb-test-build.noindex/tools/lldb-vscode/terminated-event/TestVSCode_terminatedEvent.test_terminated_event/a.out.stripped\",\"symbolTableIndexTime\":0.00067299999999999999,\"symbolTableLoadedFromCache\":false,\"symbolTableParseTime\":0.00054799999999999998,\"symbolTableSavedToCache\":false,\"symbolTableStripped\":false,\"triple\":\"x86_64--linux\",\"uuid\":\"E317E50F\"},{\"debugInfoByteSize\":833593,\"debugInfoEnabled\":true,\"debugInfoIndexLoadedFromCache\":false,\"debugInfoIndexSavedToCache\":false,\"debugInfoIndexTime\":0.012657,\"debugInfoParseTime\":0.32714500000000002,\"identifier\":93901656106336,\"path\":\"/usr/lib64/ld-2.28.so\",\"symbolTableIndexTime\":0.0017719999999999999,\"symbolTableLoadedFromCache\":false,\"symbolTableParseTime\":0.025423000000000001,\"symbolTableSavedToCache\":false,\"symbolTableStripped\":false,\"triple\":\"x86_64--linux\",\"uuid\":\"57D782C6-AF24-135E-6970-7B9D3334B91B-6CD33392\"},{\"debugInfoByteSize\":0,\"debugInfoEnabled\":false,\"debugInfoIndexLoadedFromCache\":false,\"debugInfoIndexSavedToCache\":false,\"debugInfoIndexTime\":0,\"debugInfoParseTime\":0,\"identifier\":93901654578688,\"path\":\"[vdso](0x00007ffff7ffd000)\",\"symbolTableIndexTime\":3.1000000000000001e-05,\"symbolTableLoadedFromCache\":false,\"symbolTableParseTime\":0.00038900000000000002,\"symbolTableSavedToCache\":false,\"symbolTableStripped\":false,\"triple\":\"x86_64-unknown-linux-gnu\",\"uuid\":\"B5AF4022-69CE-E598-5703-F5C62C32322D-D9CF26D1\"},{\"debugInfoByteSize\":1020,\"debugInfoEnabled\":true,\"debugInfoIndexLoadedFromCache\":false,\"debugInfoIndexSavedToCache\":false,\"debugInfoIndexTime\":0.0021559999999999999,\"debugInfoParseTime\":0.00024699999999999999,\"identifier\":140008887806080,\"path\":\"/data/users/wanyi/llvm-sand/build/Debug/fbcode-x86_64/toolchain/lldb-test-build.noindex/tools/lldb-vscode/terminated-event/TestVSCode_terminatedEvent.test_terminated_event/libfoo.so\",\"symbolTableIndexTime\":6.2000000000000003e-05,\"symbolTableLoadedFromCache\":false,\"symbolTableParseTime\":0.00080800000000000002,\"symbolTableSavedToCache\":false,\"symbolTableStripped\":false,\"triple\":\"x86_64--\",\"uuid\":\"109BFB15\"},{\"debugInfoByteSize\":0,\"debugInfoEnabled\":false,\"debugInfoIndexLoadedFromCache\":false,\"debugInfoIndexSavedToCache\":false,\"debugInfoIndexTime\":0,\"debugInfoParseTime\":0,\"identifier\":140008887859888,\"path\":\"/lib64/libdl.so.2\",\"symbolTableIndexTime\":0.000105,\"symbolTableLoadedFromCache\":false,\"symbolTableParseTime\":0.0013470000000000001,\"symbolTableSavedToCache\":false,\"symbolTableStripped\":false,\"triple\":\"x86_64--linux\",\"uuid\":\"776BF255-7FD5-1D1A-CAB0-D1D2D7568263-EC5999B5\"},{\"debugInfoByteSize\":0,\"debugInfoEnabled\":false,\"debugInfoIndexLoadedFromCache\":false,\"debugInfoIndexSavedToCache\":false,\"debugInfoIndexTime\":0,\"debugInfoParseTime\":0,\"identifier\":140008887883408,\"path\":\"/lib64/libstdc++.so.6\",\"symbolTableIndexTime\":0.038710000000000001,\"symbolTableLoadedFromCache\":false,\"symbolTableParseTime\":0.075740000000000002,\"symbolTableSavedToCache\":false,\"symbolTableStripped\":false,\"triple\":\"x86_64--linux\",\"uuid\":\"104D4081-3FC7-4F42-7CD4-AC714B249C02-DA5E62C3\"},{\"debugInfoByteSize\":0,\"debugInfoEnabled\":false,\"debugInfoIndexLoadedFromCache\":false,\"debugInfoIndexSavedToCache\":false,\"debugInfoIndexTime\":0,\"debugInfoParseTime\":0,\"identifier\":140008887951248,\"path\":\"/lib64/libm.so.6\",\"symbolTableIndexTime\":0.003212,\"symbolTableLoadedFromCache\":false,\"symbolTableParseTime\":0.027257,\"symbolTableSavedToCache\":false,\"symbolTableStripped\":false,\"triple\":\"x86_64--linux\",\"uuid\":\"089E6D24-BF02-DE2B-C57E-456118BFDC1D-691B14BB\"},{\"debugInfoByteSize\":0,\"debugInfoEnabled\":false,\"debugInfoIndexLoadedFromCache\":false,\"debugInfoIndexSavedToCache\":false,\"debugInfoIndexTime\":0,\"debugInfoParseTime\":0,\"identifier\":140008888170224,\"path\":\"/lib64/libgcc_s.so.1\",\"symbolTableIndexTime\":0.000357,\"symbolTableLoadedFromCache\":false,\"symbolTableParseTime\":0.0040460000000000001,\"symbolTableSavedToCache\":false,\"symbolTableStripped\":false,\"triple\":\"x86_64--\",\"uuid\":\"CD2F6200-D8CA-7045-ADDB-17C6C4240AAC-5DE305B1\"},{\"debugInfoByteSize\":0,\"debugInfoEnabled\":false,\"debugInfoIndexLoadedFromCache\":false,\"debugInfoIndexSavedToCache\":false,\"debugInfoIndexTime\":0,\"debugInfoParseTime\":0,\"identifier\":140008887911072,\"path\":\"/lib64/libc.so.6\",\"symbolTableIndexTime\":0.0070210000000000003,\"symbolTableLoadedFromCache\":false,\"symbolTableParseTime\":0.072236999999999996,\"symbolTableSavedToCache\":false,\"symbolTableStripped\":false,\"triple\":\"x86_64--linux\",\"uuid\":\"F65C85BF-DB90-4B62-3D4F-E2139B4D7C25-CF8C0B58\"},{\"debugInfoByteSize\":833593,\"debugInfoEnabled\":true,\"debugInfoIndexLoadedFromCache\":false,\"debugInfoIndexSavedToCache\":false,\"debugInfoIndexTime\":0.012407,\"debugInfoParseTime\":0.012078999999999999,\"identifier\":140008887927648,\"path\":\"/lib64/ld-linux-x86-64.so.2\",\"symbolTableIndexTime\":0.001758,\"symbolTableLoadedFromCache\":false,\"symbolTableParseTime\":0.022352,\"symbolTableSavedToCache\":false,\"symbolTableStripped\":false,\"triple\":\"x86_64--linux\",\"uuid\":\"57D782C6-AF24-135E-6970-7B9D3334B91B-6CD33392\"}],\"targets\":[{\"breakpoints\":[{\"details\":{\"Breakpoint\":{\"BKPTOptions\":{\"AutoContinue\":false,\"ConditionText\":\"\",\"EnabledState\":true,\"IgnoreCount\":0,\"OneShotState\":false},\"BKPTResolver\":{\"Options\":{\"NameMask\":[56],\"Offset\":0,\"SkipPrologue\":true,\"SymbolNames\":[\"foo\"]},\"Type\":\"SymbolName\"},\"Hardware\":false,\"Names\":[\"vscode\"],\"SearchFilter\":{\"Options\":{},\"Type\":\"Unconstrained\"}}},\"id\":1,\"internal\":false,\"numLocations\":1,\"numResolvedLocations\":1,\"resolveTime\":0.0020110000000000002},{\"details\":{\"Breakpoint\":{\"BKPTOptions\":{\"AutoContinue\":false,\"ConditionText\":\"\",\"EnabledState\":true,\"IgnoreCount\":0,\"OneShotState\":false},\"BKPTResolver\":{\"Options\":{\"Column\":0,\"Exact\":false,\"FileName\":\"/data/users/wanyi/llvm-sand/external/llvm-project/lldb/test/API/tools/lldb-vscode/terminated-event/main.cpp\",\"Inlines\":true,\"LineNumber\":5,\"Offset\":0,\"SkipPrologue\":true},\"Type\":\"FileAndLine\"},\"Hardware\":false,\"Names\":[\"vscode\"],\"SearchFilter\":{\"Options\":{},\"Type\":\"Unconstrained\"}}},\"id\":2,\"internal\":false,\"numLocations\":0,\"numResolvedLocations\":0,\"resolveTime\":0.22744400000000001},{\"details\":{\"Breakpoint\":{\"BKPTOptions\":{\"AutoContinue\":false,\"ConditionText\":\"\",\"EnabledState\":true,\"IgnoreCount\":0,\"OneShotState\":false},\"BKPTResolver\":{\"Options\":{\"Language\":\"c\",\"NameMask\":[4,4,4,4,4,4],\"Offset\":0,\"SkipPrologue\":false,\"SymbolNames\":[\"_dl_debug_state\",\"rtld_db_dlactivity\",\"__dl_rtld_db_dlactivity\",\"r_debug_state\",\"_r_debug_state\",\"_rtld_debug_state\"]},\"Type\":\"SymbolName\"},\"Hardware\":false,\"SearchFilter\":{\"Options\":{\"ModuleList\":[\"/usr/lib64/ld-2.28.so\"]},\"Type\":\"Modules\"}}},\"id\":-1,\"internal\":true,\"kindDescription\":\"shared-library-event\",\"numLocations\":1,\"numResolvedLocations\":1,\"resolveTime\":0.00034600000000000001}],\"expressionEvaluation\":{\"failures\":0,\"successes\":0},\"firstStopTime\":0.157499681,\"frameVariable\":{\"failures\":0,\"successes\":0},\"launchOrAttachTime\":0.117741226,\"moduleIdentifiers\":[93901655961472,93901656106336,93901654578688,140008887806080,140008887859888,140008887883408,140008887951248,140008888170224,140008887911072],\"signals\":[{\"SIGSTOP\":1}],\"sourceMapDeduceCount\":0,\"stopCount\":8,\"targetCreateTime\":0.00064000000000000005,\"totalBreakpointResolveTime\":0.22980100000000003}],\"totalDebugInfoByteSize\":1668206,\"totalDebugInfoEnabled\":3,\"totalDebugInfoIndexLoadedFromCache\":0,\"totalDebugInfoIndexSavedToCache\":0,\"totalDebugInfoIndexTime\":0.027220000000000001,\"totalDebugInfoParseTime\":0.33947100000000002,\"totalModuleCount\":10,\"totalModuleCountHasDebugInfo\":3,\"totalSymbolTableIndexTime\":0.053701000000000006,\"totalSymbolTableParseTime\":0.23014699999999999,\"totalSymbolTableStripped\":0,\"totalSymbolTablesLoadedFromCache\":0,\"totalSymbolTablesSavedToCache\":0}","type":"event"}
```

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

[ORC] Skip non-SHF_ALLOC sections in DebugObjectManagerPlugin.

We don't need to provide a load-address for non-alloc sections. Skipping them
allows us to avoid some complications, like handling duplicate .group sections.

[clang] Instantiate concepts with sugared template arguments

Since we don't unique specializations for concepts, we can just instantiate
them with the sugared template arguments, at negligible cost.

If we don't track their specializations, we can't resugar them later
anyway, and that would be more expensive than just instantiating them
sugared in the first place since it would require an additional pass.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D136566

[clang] Instantiate alias templates with sugar

This makes use of the changes introduced in D134604, in order to
instantiate alias templates witn a final sugared substitution.

This comes at no additional relevant cost.
Since we don't track / unique them in specializations, we wouldn't be
able to resugar them later anyway.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D136565

[clang] Instantiate NTTPs and template default arguments with sugar

This makes use of the changes introduced in D134604, in order to
instantiate non-type template parameters and default template arguments
with a final sugared substitution.

This comes at no additional relevant cost.
Since we don't track / unique them in specializations, we wouldn't be
able to resugar them later anyway.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D136564

[clang] Implement sugared substitution changes to infrastructure

Implements the changes required to perform substitution with
non-canonical template arguments, and to 'finalize' them
by not placing 'Subst' nodes.

A finalized substitution means we won't resugar them later,
because these templates themselves were eagerly substituted
with the intended arguments at the point of use. We may still
resugar other templates used within those, though.

This patch does not actually implement any uses of this
functionality, those will be added in subsequent patches,
so expect no changes to existing tests.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D134604

[flang] Support lowering of parent component in strecture constructor

Reuse the previous record assignment code. Use gen(expr) to generate
the fir::ExtendedValue of parent component recursively and convert the
structure to a fir.ref<T> type, where T is the record type of parent
component. Then, fir::factory::genRecordAssignment can be reused to
assign the parent component to the type-casted structure.

Reviewed By: jeanPerier

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

[flang] Add support for lowering intrinsic module procedure C_ASSOCIATED

As Fortran 2018 18.2.3.2, the arguments of C_ASSOCIATED have the same
type, a scalar of type C_PTR or C_FUNPTR, and the result has the default
logical scalar type. The interface is defined with two module procedures
c_associated_c_ptr/c_associated_c_funptr in flang/module/iso_c_binding.
The result is false if the first argument is a C null pointer. If the
second argument is present, the result is true only if the two arguments
are equal. Support the lowering by comparing the C pointer address
values of two arguments if the second argument is dynamically present
and comparing the C pointer address value of the first argument with the
value 0.

Reviewed By: jeanPerier

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

[X86] Enable reassociation for ADD instructions

ADD is an associative and commutative operation, so we can do reassociation for it.

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

[clang] Perform sugared substitution of builtin templates

Since these are much like template type aliases, where we don't
track a specialization for them and just substitute them eagerly,
we can't resugar them anyway, and there is no relevant cost in just
performing a finalizing sugared substitution.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D136563

[mlir][sparse] use loop emitter to generate loop in sparsification

Reviewed By: aartbik

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

[include-cleaner] Fix header guard. NFC

[clang] Changes to produce sugared converted template arguments

Makes CheckTemplateArgumentList and the template deduction functions
produce a sugared converted argument list in addition to the canonical one.

This is mostly NFC except that we hook this up to a few diagnostics in
SemaOverload.

The infrastructure here will be used in subsequent patches
where we perform a finalized sugared substitution for entities
which we do not unique per specializations on canonical arguments,
and later on will be used for template specialization resugaring.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D133874

SimplifyLibCalls: Add missing testcase for sincospi

Part of issue 58604. Test should have been part of
50fe87a5c8597eb72e6055356fa7dad364756ff7

GlobalISel: Fix copy paste error

Pretty sure this was harmless since the tablegen
calling convention definitions do not use pointers.

Part of issue 58604

Revert "Update supported features in the generic CPU configuration"

This reverts commit 11afbf396e10e1b1e91a5991e2aec1916e29a910.

There are 10 tests still failing after follow-up fix b5d0bf9b9853, this should get the following bots back to green:
 - https://lab.llvm.org/buildbot/#/builders/183/builds/8194
 - https://lab.llvm.org/buildbot/#/builders/186/builds/9491
 - https://lab.llvm.org/buildbot/#/builders/214/builds/3908
 - https://lab.llvm.org/buildbot/#/builders/93/builds/11740
 - https://lab.llvm.org/buildbot/#/builders/231/builds/4200
 - https://lab.llvm.org/buildbot/#/builders/121/builds/24519
 - https://lab.llvm.org/buildbot/#/builders/230/builds/4466
 - https://lab.llvm.org/buildbot/#/builders/94/builds/11639
 - https://lab.llvm.org/buildbot/#/builders/45/builds/9325
 - https://lab.llvm.org/buildbot/#/builders/124/builds/5219
 - https://lab.llvm.org/buildbot/#/builders/67/builds/8623
 - https://lab.llvm.org/buildbot/#/builders/123/builds/13836
 - https://lab.llvm.org/buildbot/#/builders/109/builds/49355
 - https://lab.llvm.org/buildbot/#/builders/58/builds/27751
 - https://lab.llvm.org/buildbot/#/builders/117/builds/9922
 - https://lab.llvm.org/buildbot/#/builders/16/builds/37012
 - https://lab.llvm.org/buildbot/#/builders/104/builds/9490
 - https://lab.llvm.org/buildbot/#/builders/42/builds/7725
 - https://lab.llvm.org/buildbot/#/builders/196/builds/20077
 - https://lab.llvm.org/buildbot/#/builders/3/builds/15217
 - https://lab.llvm.org/buildbot/#/builders/6/builds/15251
 - https://lab.llvm.org/buildbot/#/builders/9/builds/15247
 - https://lab.llvm.org/buildbot/#/builders/36/builds/26487
 - https://lab.llvm.org/buildbot/#/builders/54/builds/2474
 - https://lab.llvm.org/buildbot/#/builders/74/builds/14536
 - https://lab.llvm.org/buildbot/#/builders/5/builds/28555

Revert "[wasm-ld] Add -mcpu=mvp to wasm-ld tests"

This reverts commit b5d0bf9b9853688d34290fafdd31c95aca58f624.

The original commit is causing 10 test failures on multiple bots, reverting to get back to green.

[libc] Enable a few entrypoints on aarch64 already available on x86_64.

[FuncSpec] Fix missed opportunities for function specialisation

When collecting the possible constant arguments to
specialise a function the compiler will abandon the search
on the first argument that is for some reason unsuitable as
a specialisation constant. Thus, depending on the traversal
order of the functions and call sites, the compiler can end
up with a different set of possible constants, hence with
different set of specialisations.

With this patch, the compiler will skip unsuitable
constants, but nevertheless will continue searching for
more.

Reviewed By: ChuanqiXu

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

[trace][intel pt][simple] Fix errors after switching to libipt's top of tree

These tests were being tested against a version of libipt from last
year. We just updated libipt to top of tree and many errors broke
because the new version of libipt emits more events than the older one,
which is fine.

`./bin/lldb-dotest -p TestTrace` passes

[LV][RISCV] Disable vectorization of epilogue loops

Epilogue loop vectorization is a feature in the vectorize intended to avoid running fully scalar code when the vector length of the main loop turns out to be either longer than the trip count of the actual loop, or with a huge remainder.

In practice, this feature appears to not have been well tuned. I honestly don't think it should be on by default at all, but it definitely shouldn't be on for RISCV. Note that other targets have also disabled it, but they've done so via disabling interleaving - which is, well, completely unrelated - and we don't want to do that for RISCV.

In the near term, many examples I'm seeing have terrible codegen for epilogue vectorization. We are greatly increasing code size for little value at reasonable VLEN values for small types. In the long term, the cases that epilogue vectorization are intended to handle are likely better handled via tail folding on RISCV.

As an aside, I also don't really trust the correctness of epilogue vectorization. The code structure is such that otherwise straight forward changes sometimes break only epilogue vectorization. The reuse of an existing vplan without careful validation opens significant room for nasty bugs. Given how rarely the code is exercised, that is not a good combination.

As such, this patch introduces a TTI hook, and completely disables epilogue vectorization on RISCV.

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

Quick fix for previous commit; small code change before commit

Change debugserver to clear PAC auth bits manually

debugserver is currently using kernel supplied macros,
arm_thread_state64_get_{pc,fp,sp,lr} which can crash on an authorization
failure when the inferior has crashed with an invalid pc value, for
instance.  debugserver needs to be resistant to crashing in this
scenario, and we're merely clearing the bits, so do it with a bit
mask operation instead.

Differential Revision: https://reviews.llvm.org/D136620
rdar://98073271
rdar://100663221

[clang-doc] Fix typedef/using output.

Provides an initializer for the TypedefInfo.IsUsing member. Previously
this member was uninitialized and would produce random output.

Adds the Description (code comments) to the bitcode reader/writer.
Previously the typedef/using descriptions were lost during the bitcode
round-trip. Adds a test for this.

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

[lld-macho] Don't sort map file entries by name

ld64 emits them in address order but not in alphabetical order. This
sorting is particularly expensive for dead-stripped symbols (which don't
need to be sorted at all, unlike live symbols that need to be sorted by
address).

Timings for chromium_framework_less_dwarf (with the `-map` flag added to
the response file) on my 16-core Mac Pro:

             base           diff           difference (95% CI)
  sys_time   1.997 ± 0.038  2.004 ± 0.028  [  -0.6% ..   +1.3%]
  user_time  8.698 ± 0.085  8.167 ± 0.070  [  -6.6% ..   -5.6%]
  wall_time  7.965 ± 0.114  7.715 ± 0.347  [  -5.1% ..   -1.2%]
  samples    25             23

Reviewed By: #lld-macho, thakis

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