This reverts commit 2217837c.

This adds tests for `generic` cpu configuration. We had tests for `mvp`
and `bleeding-edge` configs but not `generic`.

Add a new --summary option to statistics dump command so that it is
much more light weight than the full version.
Introduce a new SBStatisticsOptions API setting the verbosity of statistics dump. 
[PR
#80218](https://github.com/llvm/llvm-project/pull/80218#discussion_r1473639878)

Fixes llvm/llvm-project#63241

Doxygen commands can start with `@` or `\`.

Debug notes for unclaimed DeclRefExpr should report any DRE of an unsafe
variable that is not covered by a Fixable (i. e. fixit for the
particular AST pattern isn't implemented for whatever reason). Currently
not all unclaimed DeclRefExpr-s are reported which is a bug. The debug
notes report only those DREs where the referred VarDecl has at least one
other DeclRefExpr which is claimed (covered by a fixit). If there is an
unsafe VarDecl that has exactly one DRE and the DRE isn't claimed then
the debug note about missing fixit won't be emitted. That is because the
debug note is emitted from within a loop over set of successfully
matched FixableGadgets which by-definition is missing those DRE that are
not matched at all.

The new code simply iterates over all unsafe VarDecls and all of their
unclaimed DREs.

This patch adds tests that lock down the ABI of types like deque, list
and vector.
An upcoming patch will replace the usage of __compressed_pair in these
classes
by [[no_unique_address]], so we are adding these tests to pin down their
ABI
before making the change. That way, we can be confident that the patch
making
the actual ABI-sensitive change is safe if it doesn't break these tests.

Add isWasm() check for here:
https://github.com/llvm/llvm-project/pull/78655#issuecomment-1928075569

Add facts for llvm.abs >= 0.

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

This fixes a breakage caused by e9763854

We can use BinarySection::updateContents() to change section contents.
However, if we also add relocations for new contents, then the original
data (i.e. not updated) is going to be used. Fix that. A follow-up diff
will use the update interface and will include a test case.

This adds the SMMLA, UMMLA, and  USMMLA intrinsics to Neon dialect bringing it in line with the SVE dialect. 

These ops enable matrix multiply-accumulate instructions with two e 2x8 matrix inputs of respective signage into a 2x2 32-bit integer accumulator. This is equivalent to performing an 8-way dot product per destination element.

Op details: 
https://developer.arm.com/architectures/instruction-sets/intrinsics/#f:@navigationhierarchiessimdisa=[Neon]&q=mmla

Seen several beginner questions popping up in discourse about how to
implement and run custom passes. And then it turns out that they are
following the old "Writing an LLVM Pass" guide that describe legacy
passes, and then things are mixed up when they try to run that pass
using opt that nowadays default to the new pass manager.

This is an attempt to make it slightly clearer in the User Guides that
there are two different "Writing an LLVM Pass" pages depending on which
pass manager that should be used. This is done by renaming the legacy
version of "Writing an LLVM Pass" as "Writing an LLVM Pass (legacy PM
version)".
Also reordered the links to put the link to the new pass manager
documentation first.

This patch also moves the warning text that cross references the
description on how to write a pass for legacy/new PM to make sure it
ends up already in the beginning of the descriptions.

Also adding a new warning in the "Running a pass with opt" section of
the legacy PM version of the guide, to inform that those examples are
outdated.

A user found a crash when they would do code like:
```
(lldb) script
>>> target = lldb.SBTarget()
>>> lldb.debugger.SetSelectedTarget(target)
```

We were not checking if the target was valid in and it caused a crash..

If the `_LIBCPP_HARDENING_MODE_DEFAULT` macro is not defined,
`_LIBCPP_HARDENING_MODE` will be considered defined but fail the check
for a valid hardening mode, resulting in a slightly less understandable
error (that error is really meant more to prevent users from passing
incorrect values such as `0` or `1` directly rather than catching
configuration issues).

This is a follow up to #80351 and adds private and reduction operands
from acc.loop, acc.parallel and acc.serial operations.

When building without unified_shared_memory, global variables are
declared in the device binary and allocated upon loading onto GPU
memory. However, when running in zero-copy mode (same as with
unified_shared_memory) D2H and H2D copies for mapped local and global
variables are turned off. This patch turns back on H2D and D2H copies
when they refer to global variables, enabling an application built
without unified_shared_memory to work correctly with global variables
when run under automatic zero-copy.

Co-authored-by: Doru Bercea <doru.bercea@amd.com>
Co-authored-by: Jan-Patrick Lehr <janpatrick.lehr@amd.com>

Per the approved resolution for CWG2847, [temp.expl.spec] p8 will state:
> An explicit specialization shall not have a trailing _requires-clause_ unless it declares a function template.

We already implement this _partially_ insofar that a diagnostic is issued upon instantiation of `A<int>` in the following example:
```
template<typename>
struct A
{
    template<typename>
    void f();

    template<>
    void f<int>() requires true; // error: non-templated function cannot have a requires clause
};
template struct A<int>;  // note: in instantiation of template class 'A<int>' requested here
```

This patch adds a bespoke diagnostic for such declarations, and moves the point of diagnosis for non-templated functions with trailing requires-clauses from `CheckFunctionDeclaration` to `ActOnFunctionDeclarator` (there is no point in diagnosing this during instantiation since we already have all the necessary information when parsing the declaration).

Link: https://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322

Binary operators are also of struct type in C, when assigning. Don't try to get the ComparisonCategoryInfo in that case.

Link: https://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322

This implements the minimum amout of support for this feature
to get the test/AST/ms-constexpr.cpp test working. More has to
be added to get SemaCXX tests to work.

Found while auditing places where we only check C and not Zca.

This patch adds a new interface for the join operation, now properly
called `join`. Originally, the framework offered a single `merge`
operation, which could serve either as a join or a widening. In
practice, though we found this conflation didn't work for non-trivial
anlyses, and split of the widening operation (`widen`). This change
completes the transition by introducing a proper `join` with strict join
semantics.

In the process, it drops an odd (and often misused) aspect of `merge`
wherein callees could implictly instruct the framework to drop the
current entry by returning `false`. This features was never used
correctly in analyses and doesn't belong in a join operation, so it is
omitted.

---------

Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
Co-authored-by: martinboehme <mboehme@google.com>

This patch canonicalizes the fcmp range check idiom into `fabs + fcmp`
since the canonicalized form is better than the original form for the
backends.
Godbolt: https://godbolt.org/z/x3eqPb1fz
```
and (fcmp olt/ole/ult/ule x, C), (fcmp ogt/oge/ugt/uge x, -C) --> fabs(x) olt/ole/ult/ule C
or  (fcmp ogt/oge/ugt/uge x, C), (fcmp olt/ole/ult/ule x, -C) --> fabs(x) ogt/oge/ugt/uge C
```
Alive2: https://alive2.llvm.org/ce/z/MRtoYq

With e8512786 the for loop that iterates
over MDNode operands was changed to a range-based for loop. This change
surfaces a bug where if the result of MD->operands() is an ArrayRef that
has a size of 0, then iterating over that ArrayRef leads to a
segmentation fault, due to accessing invalid addresses.
    
This was reverted with 6ce03ff3 but this
test should be added to test that codepath in the future.

We had "+zca" instead of "zca". The previous line used "c", not "+c".

This may not be a functional change. I think the function we pass this
to strips any '+' or '-'.

Add clang-tidy check to suggest replacement of conditional statement with std::min/std::max (#77816)

This pull request fixes #64914 where author suggests adding a
readability check to propose the replacement of conditional statements
with std::min/std::max for improved code readability. Additionally,
reference is made to PyLint's similar checks:
[consider-using-min-builtin](https://pylint.pycqa.org/en/latest/user_guide/messages/refactor/consider-using-min-builtin.html)
and
[consider-using-max-builtin](https://pylint.pycqa.org/en/latest/user_guide/messages/refactor/consider-using-max-builtin.html)

In github PR #78731 it looks like I added test coverage for RemoveDIs to
either the wrong test, or not enough. Adding
--try-experimental-debuginfo-iterators to this particular test is enough to
restore some coverage it seems.

This adds missing features to the tests and removes a stale feature
(unimplemented_simd128) from them.

The pread function wasn't properly unpoisoning its result under msan,
causing test failures downstream when I tried to roll it out. This patch
adds the msan unpoison call that fixes the issue.