[llvm-objcopy][MachO] Fix adding multiple sections

This diff fixes missing fields initialization (Size, VMSize).
Previously this resulted in broken binaries when multiple sections
were added in one tool's invocatation.

Test plan: make check-all

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

[AMDGPU] SIWholeQuadMode fix mode insertion when SCC always defined

Fix a crash when SCC is defined until end of block and mode change
must be inserted in SCC live region.

Reviewed By: mceier

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

Include the generated documentation for list of ops in the TOSA dialect

Fix dumping of explicit template specializations

This was missing from commit 7efe07a1 (Traverse-ignore explicit template
instantiations, 2020-11-06).

[RISCV] Add test cases showing missed opportunities to use sbset/sbclr/sbinv/sbext when the shift amount isn't masked to log2(xlen) bits. NFC

Out of bounds shifts are undefined and these instructions mask
their shift amount before use. So we don't need to see a mask
in order to select the instructions.

[docs] Adding a Support Policy

As discussed in the mailing list [1-4], we need a separation of support
tiers when requiring support from the whole community versus a
sub-community. Essentially, if a sub-community is active enough and
takes maintenance into their own internal costs without affecting other
parts of the community's maintenance costs, then code that is not
immediately relevant to all parts (ie. not released, actively tested,
etc) can still find its way into the LLVM main repository without major
pain points.

The main benefit is to reduce the maintenance cost that those
sub-communities have outside of LLVM (for example, in duplicating common
code, applying the same patches on top of multiple user repositories or
downstream projects).

This document outlines the components and responsibilities of the
sub-communities with regards to maintenance costs and how they affect
the rest of the community.

It also adds an addendum on removal policies, which expand the existing
"new target removal" policy into something more generic, to encompass
any piece of code, scripts or documents in the repository.

[1] http://lists.llvm.org/pipermail/llvm-dev/2020-October/146249.html
[2] http://lists.llvm.org/pipermail/llvm-dev/2020-November/146335.html
[3] http://lists.llvm.org/pipermail/llvm-dev/2020-October/146138.html
[4] http://lists.llvm.org/pipermail/llvm-dev/2020-November/146298.html

[RISCV] Use (not X) in instead of (xor X, -1) in isel patterns to improve readability. NFC

[gn build] Port d725f1ce531

[clang-tidy] Use vfs::FileSystem when getting config

The config providers that look for configuration files currently take a pointer to a FileSystem in the constructor.
For some reason this isn't actually used when trying to read those configuration files, Essentially it just follows the behaviour of the real filesystem.
Using clang-tidy standalone this doesn't cause any issue.
But if its used as a library and the user wishes to use say an `InMemoryFileSystem` it will try to read the files from the disc instead.

Reviewed By: aaron.ballman

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

Add missing dependency to TOSA library: fix build with -DBUILD_SHARED_LIBS=ON

Refactor TOSA Dialect CMake to use add_mlir_dialect/add_mlir_interface (NFC)

[DWARFLinker] Convert analyzeContextInfo to a work list (NFC)

Convert analyzeContextInfo to a work list using the same approach I used
to remove the recursion from lookForDIEsToKeep. This fixes the crash
reported in https://llvm.org/PR48029.

Tested using the reproducer attached to PR48029 as well as by comparing
the clang MD5 hashes before and after the change (with and without
gmodules).

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

[lldb] [test] Use skipUnlessDarwin for tests specific to Darwin

Use skipUnlessDarwin decorator for tests that are specific to Darwin,
instead of skipIf... for all other platforms.  This should make it clear
that these tests are not supposed to work elsewhere.  It will also make
these tests stop repeatedly popping up while I look for tests that could
be fixed on the platform in question.

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

[lldb] [test] Un-skip one of TestRaise signals on fbsd

NFC: (re-apply) Fix some post-review nits for the Tosa dialect.

This reverts commit 330398052d049f90e6cfac80ab8b765b158a3e61.

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

[BasicAA] Unify struct/other offset (NFC)

The distinction between StructOffset and OtherOffset has been
originally introduced by 82069c44ca39df9d506e16bfb0ca2481866dd0bb,
which applied different reasoning to both offset kinds. However,
this distinction was not actually correct, and has been fixed by
c84e77aeaefccb8d0c4c508b8017dcad80607f53. Since then, we only ever
consider the sum StructOffset + OtherOffset, so we may as well
store it in that form directly.

Revert "NFC: Fix some post-review nits for the Tosa dialect."

* Introduced issue in debug builds.

This reverts commit b5fcd06105dec2a7b0e4114d6ad4524fc54498c5.

[BasicAA] Use smul_ov helper (NFCI)

Instead of performing the multiplication in double the bit width
and using active bits to determine overflow, use the existing
smul_ov() APInt method to detect overflow.

The smul_ov() implementation is not particularly efficient, but
it's still better than doing this a wide, usually 128-bit, type.

[mlir][Python] Adapt to include property change in pybind11 v2.6.

Reviewed By: mehdi_amini

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

NFC: Fix some post-review nits for the Tosa dialect.

* Moved various loose functions to either the mlir::tosa namespace or made static
* Fixed an unused variable warning in TosaMakeBroadcastable.cpp.

TOSA MLIR Dialect

This is the TOSA MLIR Dialect described in the following MLIR RFC: https://llvm.discourse.group/t/rfc-tosa-dialect-in-mlir/1971/24

Reviewed By: stellaraccident

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

[clang] Fix length threshold for MicrosoftMangle md5 hash

Reviewers: rnk, dblaikie

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

[clang] Improve Microsoft mangling lit test with dblaikie's suggestions

[CaptureTracking] Add statistics (NFC)

Add basic statistics on the number of pointers that have been
determined to maybe capture / not capture.

[CaptureTracking] Early abort on too many uses (NFCI)

If there are too many uses, we should directly return -- there's
no point in inspecting the remaining uses in the worklist, as we
have to conservatively assume a capture anyway. This also means
that tooManyUses() gets called exactly once, rather than
potentially many times.

This restores the behavior prior to e9832dfdf366ddffba68164adb6855d17c9f87c1,
where this was accidentally changed while moving the AddUses logic
into a closure, thus making the return a return from the closure
rather than the whole function.

[CaptureTrackingTest] Add missing override marker (NFC)

[CaptureTracking] Correctly handle multiple uses in one instruction

If the same value is used multiple times in the same instruction,
CaptureTracking may end up reporting the wrong use as being captured,
and/or report the same use as being captured multiple times.

Make sure that all checks take the use operand number into account,
rather than performing unreliable comparisons against the used value.

I'm not sure whether this can cause any problems in practice, but
at least some capture trackers (ArgUsesTracker, AACaptureUseTracker)
do care about which call argument is captured.

[MLIR][SPIRVToLLVM] Added module name conversion

Since SPIR-V module has an optional name, this patch
makes a change to pass it to `ModuleOp` during conversion.

Reviewed By: ftynse

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

[CaptureTracking] Avoid duplicate shouldExplode() check (NFCI)

We check shouldExplore() before adding uses to the worklist, so
uses that should not be explored will not reach captured() in the
first place.

[DWARFLinker] Use union to reduce sizeof(WorklistItem) (NFC)

Reduce the size of the WorklistItem struct by using a struct.

[BranchProbabilityInfo] Simplify getEdgeProbability (NFC)

The patch simplifies BranchProbabilityInfo::getEdgeProbability by
handling two cases separately, depending on whether we have edge
probabilities.

- If we have edge probabilities, then add up probabilities for
  successors being equal to Dst.

- Otherwise, return the number of ocurrences divided by the total
  number of successors.

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

[test] Fix Other/new-pass-manager.ll with has different behaviors whether or not Polly is enabled

after D89158

[test] Fix Other/new-pass-manager.ll & clang/test/Misc/loop-opt-setup.c

Revert "[LoopDeletion] Allows deletion of possibly infinite side-effect free loops"

This reverts commit 0b17c6e4479d62bd4ff05c48d6cdf340b198832f. This patch
causes a compile-time error in SCEV.

Revert "[CodeGen] Fixes sanitizer test"

This reverts commit b1878b4641e06baa754ce6e3e0387b1e7d7dc143. This does
fix the test but it means that ac73b73c1652 is not implemented
correctly. Reverting for now, and will be reverting the commit that
causes this to fail.

AsmPrinter/Dwarf*: Use llvm::Register instead of unsigned

[CodeGen] Fixes sanitizer test

By turning the loop into an infinite one, the loop can't be deleted
anymore so the test will continue to pass.

[OpenMP] Fix -Wmisleading-indentation after D84192

[AsmPrinter] Rename ByteStreamer::EmitInt8 to emitInt8

to be consistent with other emit*

[LoopDeletion] Fixes failing test

The commit 0b17c6e4479d62bd4ff05c48d6cdf340b198832f occasionally causes this test to
fail, this fixes it.

[DWARFLinker] Add CompileUnit::getInfo helper that takes a DWARFDie (NFC)

Eliminate the need to go through the DIE index by passing the DIE to
CompileUnit::getInfo directly.

Before:

  unsigned Idx = Unit->getOrigUnit().getDIEIndex(Die);
  CompileUnit::DIEInfo &Info = Unit->getInfo(Idx);

After:

  CompileUnit::DIEInfo &Info = Unit->getInfo(Die);

[LoopDeletion] Allows deletion of possibly infinite side-effect free loops

From C11 and C++11 onwards, a forward-progress requirement has been
introduced for both languages. In the case of C, loops with non-constant
conditionals that do not have any observable side-effects (as defined by
6.8.5p6) can be assumed by the implementation to terminate, and in the
case of C++, this assumption extends to all functions. The clang
frontend will emit the `mustprogress` function attribute for C++
functions (D86233, D85393, D86841) and emit the loop metadata
`llvm.loop.mustprogress` for every loop in C11 or later that has a
non-constant conditional.

This patch modifies LoopDeletion so that only loops with
the `llvm.loop.mustprogress` metadata or loops contained in functions
that are required to make progress (`mustprogress` or `willreturn`) are
checked for observable side-effects. If these loops do not have an
observable side-effect, then we delete them.

Loops without observable side-effects that do not satisfy the above
conditions will not be deleted.

Reviewed By: jdoerfert

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

[OpenMP5.0] map item can be non-contiguous for target update

In order not to modify the `tgt_target_data_update` information but still be
able to pass the extra information for non-contiguous map item (offset,
count, and stride for each dimension), this patch overload `arg` when
the maptype is set as `OMP_MAP_DESCRIPTOR`. The origin `arg` is for
passing the pointer information, however, the overloaded `arg` is an
array of descriptor_dim:

struct descriptor_dim {
  int64_t offset;
  int64_t count;
  int64_t stride
};

and the array size is the same as dimension size. In addition, since we
have count and stride information in descriptor_dim, we can replace/overload the
`arg_size` parameter by using dimension size.

For supporting `stride` in array section, we use a dummy dimension in
descriptor to store the unit size. The formula for counting the stride
in dimension D_n: `unit size * (D_0 * D_1 ... * D_n-1) * D_n.stride`.

Demonstrate how it works:
```
double arr[3][4][5];

D0: { offset = 0, count = 1, stride = 8 }                                // offset, count, dimension size always be 0, 1, 1 for this extra dimension, stride is the unit size
D1: { offset = 0, count = 2, stride = 8 * 1 * 2 = 16 }                   // stride = unit size * (product of dimension size of D0) * D1.stride = 4 * 1 * 2 = 8
D2: { offset = 2, count = 2, stride = 8 * (1 * 5) * 1 = 40  }            // stride = unit size * (product of dimension size of D0, D1) * D2.stride = 4 * 5 * 1 = 20
D3: { offset = 0, count = 2, stride = 8 * (1 * 5 * 4) * 2 = 320 }        // stride = unit size * (product of dimension size of D0, D1, D2) * D3.stride = 4 * 25 * 2 = 200

// X here means we need to offload this data, therefore, runtime will transfer
// data from offset 80, 96, 120, 136, 400, 416, 440, 456
// Runtime patch: https://reviews.llvm.org/D82245
// OOOOO OOOOO OOOOO
// OOOOO OOOOO OOOOO
// XOXOO OOOOO XOXOO
// XOXOO OOOOO XOXOO
```

Reviewed By: ABataev

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

[libomptarget] Add support for target update non-contiguous

This patch is the runtime support for https://reviews.llvm.org/D84192.

In order not to modify the tgt_target_data_update information but still be
able to pass the extra information for non-contiguous map item (offset,
count, and stride for each dimension), this patch overload arg when
the maptype is set as OMP_TGT_MAPTYPE_DESCRIPTOR. The origin arg is for
passing the pointer information, however, the overloaded arg is an
array of descriptor_dim:

```
struct descriptor_dim {
  int64_t offset;
  int64_t count;
  int64_t stride
};
```

and the array size is the dimension size. In addition, since we
have count and stride information in descriptor_dim, we can replace/overload the
arg_size parameter by using dimension size.

Reviewed By: grokos

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

Don't link any LLVM/MLIR library to the C API unit-test

The tests are intended to exercise the public C API and will link to a
specific shared library exposing only the C API, this library itself may
link to libMLIR.so.
If we link some LLVM library statically in the test themselves, we end
up with duplicated cl::opt registrations in LLVM. A possible setup if
these libraries were needed could be to link libMLIR.so directly when
available and link statically when it isn't available (in which case the
libary exposing the C API would be statically link and isolated from the
cl::opt registry, hopefully).

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

[Inliner] Handle `mustprogress` functions

When inlining `mustprogress` functions, if the caller or the callee has
the attribute, we drop the function attribute. The loops that have the
`llvm.loop.mustprogress` metadata keep their metadata. We do not need to
add new loop metadata to inlined functions because the patch in D86841
already adds the relevant loop metadata in all of the necessary places.

Reviewed By: jdoerfert

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

[test] -mtriple=x86_64-* -> -mtriple=x86_64

[mlir][Python] Fix cmake typo keeping the extension from installing.

[libc] Extend WrapperGen to emit aliases.

Reviewed By: michaelrj

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

[llvm-cov] Fix missing slash in -path-equivalence

[AArch64] Add driver tests for HiSilicon's TSV110

[mlir][Linalg] Canonicalize duplicate args.

I ran into this pattern when converting elementwise ops like
`addf %arg0, %arg : tensor<?xf32>` to linalg. Redundant arguments can
also easily arise from linalg-fusion-for-tensor-ops.

Also, fix some small bugs in the logic in
LinalgStructuredOpsInterface.td.

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

Revert "Allow running back-deployment testing against libc++abi"

This reverts commit 4d79ef814aedb63, which broke a few build bots.
I'm reverting until I have time to investigate.

[AArch64] Add pipeline model for HiSilicon's TSV110

This patch adds the scheduling and cost model for TSV110.

Reviewed by: SjoerdMeijer, bryanpkc

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

[TableGen] Use llvm::is_contained (NFC)

[ms] [llvm-ml] Allow arbitrary strings as integer constants

MASM interprets strings in expression contexts as integers expressed in big-endian base-256, treating each character as its ASCII representation.

This completely eliminates the need to special-case single-character strings.

Reviewed By: thakis

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

[LoopDeletion] Remove dead loops with no exit blocks

Currently, LoopDeletion refuses to remove dead loops with no exit blocks
because it cannot statically determine the control flow after it removes
the block. This leads to miscompiles if the loop is an infinite loop and
should've been removed.

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

[llvm-objcopy][MachO] Skip sections with zero offset

Some binaries can contain regular sections with zero offset and zero size.
This diff makes llvm-objcopy's handling of such sections consistent with
cctools's strip (which doesn't modify them),
previously the tool would allocate file space for them.

Test plan: make check-all

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

[debuginfo-tests] Skip optnone-loops.cpp on Darwin

This is failing on GreenDragon:
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/24745/

Add new matchers for dependent names in templates

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

Fix gcc warning by removing extra `;` after a macro (NFC)

[obj2yaml] [yaml2obj] Add yaml support for SHT_LLVM_BB_ADDR_MAP section.

YAML support allows us to better test the feature in the subsequent patches. The implementation is quite similar to the .stack_sizes section.

Reviewed By: jhenderson, grimar

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

[clangd] Set the User option for clang-tidy to mimick its behaviour

Probably not essential as afaik only one check uses this field. but still good to have consistent behaviour.

Reviewed By: sammccall

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

Fix unwind info relocation with large code model on AArch64

Makes sure that the unwind info uses 64bits pcrel relocation if a large code model is specified and handle the corresponding relocation in the ExecutionEngine. This can happen with certain kernel configuration (the same as the one in https://reviews.llvm.org/D27609, found at least on the ArchLinux stock kernel and the one used on https://www.packet.net/) using the builtin JIT memory manager.

Co-authored-by: Yichao Yu <yyc1992@gmail.com>
Differential Revision: https://reviews.llvm.org/D27629

[libc][WrapperGen] Replace the C _Noreturn annotation with C++ [[noreturn]].

Reviewed By: michaelrj

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

[RTDYLD] support absolute relocations where needed

These appear in some sections, such as DWARF tables, since
RuntimeDyldELF explicitly maps to this as a sentinel value:
https://github.com/llvm/llvm-project/blob/29d1fba7b5335d969e3e5daa84b7a25cd1fa75ef/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp#L1199

That could then be a source of problems if it tried to examine these
sections (for example, with either setProcessAllSections(true) or ORCv2 on i686).

Replaces https://reviews.llvm.org/D89241

Reviewed By: lhames, vchuravy

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

[BranchProbabilityInfo] Use succ_size (NFC)

[RISCV] Add test case to show incorrect matching to sroiw when the or mask does not have 1s in the upper 32 bits.

The matching code for sroiw is truncating the mask to 32 bits before
checking its value. We need to check all 64 bits.

Prevent LICM and machineLICM from hoisting convergent operations

Results of convergent operations are implicitly affected by the
enclosing control flows and should not be hoisted out of arbitrary
loops.

Patch by Xiaoqing Wu <xiaoqing_wu@apple.com>

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

[lldb] add a missing dependency on intrinsics_gen

Sometimes builds will fail with errors like:

```
In file included from /build/external/llvm-project/lldb/source/Symbol/SwiftASTContext.cpp:52:
In file included from /build/external/swift/include/swift/IRGen/Linking.h:22:
In file included from /build/external/swift/include/swift/SIL/SILFunction.h:24:
In file included from /build/external/swift/include/swift/SIL/SILBasicBlock.h:23:
In file included from /build/external/swift/include/swift/SIL/SILInstruction.h:21:
In file included from /build/external/swift/include/swift/AST/Builtins.h:24:
**/build/external/llvm-project/llvm/include/llvm/IR/Attributes.h:74:14: fatal error: 'llvm/IR/Attributes.inc' file not found**
**^~~~~~~~~~~~~~~~~~~~~~~~**
```
This change ensures the `Attributes.inc` file is generated before building `SwiftASTContext.cpp`.

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

[mlir] Use PyValue instead of PyOpResult in Python operand container

The PyOpOperands container was erroneously constructing objects for
individual operands as PyOpResult. Operands in fact are just values,
which may or may not be results of another operation. The code would
eventually crash if the operand was a block argument. Add a test that
exercises the behavior that previously led to crashes.

Reviewed By: stellaraccident

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

Revert "[mlir][CAPI] Proposal: Always building a libMLIRPublicAPI.so."

This reverts commit 80fe2f61fac9f72825f907637a9c63aca32d8f14.

Broke linkage with GNU ld. See original review thread for more details.

[OpenMP] Fix potential division by 0

This patch fixes potential division by 0 in case hwloc does not
recognize cores (or architecture has no cores).

Patch by Andrey Churbanov

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

[scudo][standalone] Simplify populateFreelist

`populateFreelist` was more complicated that it needed to be. We used
to call to `populateBatches` that would do some internal shuffling and
add pointers one by one to the batches, but ultimately this was not
needed. We can get rid of `populateBatches`, and do processing in
bulk. This doesn't necessarily make things faster as this is not on the
hot path, but it makes the function cleaner.

Additionally clean up a couple of items, like `UNLIKELY`s and setting
`Exhausted` to `false` which can't happen.

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

[InstCombine] computeKnownBitsMul - use KnownBits::isNonZero() helper.

Avoid an expensive isKnownNonZero() call - this is a small cleanup before moving the extra NSW functionality from computeKnownBitsMul into KnownBits::computeForMul.

[SLP][AMDGPU] Regenerate packed-math tests and remove unused check prefix

[VectorCombine][X86] Removed unused check prefixes

[mlir][CAPI] Proposal: Always building a libMLIRPublicAPI.so.

We were discussing on discord regarding the need for extension-based systems like Python to dynamically link against MLIR (or else you can only have one extension that depends on it). Currently, when I set that up, I piggy-backed off of the flag that enables build libLLVM.so and libMLIR.so and depended on libMLIR.so from the python extension if shared library building was enabled. However, this is less than ideal.

In the current setup, libMLIR.so exports both all symbols from the C++ API and the C-API. The former is a kitchen sink and the latter is curated. We should be splitting them and for things that are properly factored to depend on the C-API, they should have the option to *only* depend on the C-API, and we should build that shared library no matter what. Its presence isn't just an optimization: it is a key part of the system.

To do this right, I needed to:

* Introduce visibility macros into mlir-c/Support.h. These should work on both *nix and windows as-is.
* Create a new libMLIRPublicAPI.so with just the mlir-c object files.
* Compile the C-API with -fvisibility=hidden.
* Conditionally depend on the libMLIR.so from libMLIRPublicAPI.so if building libMLIR.so (otherwise, also links against the static libs and will produce a mondo libMLIRPublicAPI.so).
* Disable re-exporting of static library symbols that come in as transitive deps.

This gives us a dynamic linked C-API layer that is minimal and should work as-is on all platforms. Since we don't support libMLIR.so building on Windows yet (and it is not very DLL friendly), this will fall back to a mondo build of libMLIRPublicAPI.so, which has its uses (it is also the most size conscious way to go if you happen to know exactly what you need).

Sizes (release/stripped, Ubuntu 20.04):

Shared library build:
libMLIRPublicAPI.so: 121Kb
_mlir.cpython-38-x86_64-linux-gnu.so: 1.4Mb
mlir-capi-ir-test: 135Kb
libMLIR.so: 21Mb

Static build:
libMLIRPublicAPI.so: 5.5Mb (since this is a "static" build, this includes the MLIR implementation as non-exported code).
_mlir.cpython-38-x86_64-linux-gnu.so: 1.4Mb
mlir-capi-ir-test: 44Kb

Things like npcomp and circt which bring their own dialects/transforms/etc would still need the shared library build and code that links against libMLIR.so (since it is all C++ interop stuff), but hopefully things that only depend on the public C-API can just have the one narrow dep.

I spot checked everything with nm, and it looks good in terms of what is exporting/importing from each layer.

I'm not in a hurry to land this, but if it is controversial, I'll probably split off the Support.h and API visibility macro changes, since we should set that pattern regardless.

Reviewed By: mehdi_amini, benvanik

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

[FPEnv] Use strictfp metadata in casting nodes

The strictfp metadata was added to the casting AST nodes in D85960, but
we aren't using that metadata yet. This patch adds that support.

In order to avoid lots of ad-hoc passing around of the strictfp bits I
updated the IRBuilder when moving from a function that has the Expr* to a
function that lacks it. I believe we should switch to this pattern to keep
the strictfp support from being overly invasive.

For the purpose of testing that we're picking up the right metadata, I
also made my tests use a pragma to make the AST's strictfp metadata not
match the global strictfp metadata. This exposes issues that we need to
deal with in subsequent patches, and I believe this is the right method
for most all of our clang strictfp tests.

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

[TableGen] Indentation and whitespace fixes in generated code. NFC.

Some of these were found by running clang-format over the generated
code, although that complains about far more issues than I have fixed
here.

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

[AMDGPU] Simplify exp target parsing

Treat any identifier as a potential exp target and diagnose them all the
same way as "invalid exp target"s.

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

[analyzer][NFCi] Mark CallEvent::getOriginExpr virtual, some cleanup

Previously we just shadowed the original implementation with a virtual
declaration - which is really bugprone in a long run.

This patch marks `CallEvent::getOriginExpr` virtual to let subclasses
override it's behavior.
At the same time, I checked all virtual functions of this class hierarchy
to make sure we don't suffer from this elsewhere.
Removes redundant declarations of `virtual` if `override` is already present.

In theory, this patch is a functional change, but no tests were broken.
I suspect that there were no meaningful changes in behavior in the
subclasses compared to the shadowed `CallEvent::getOriginExpr`.

That being said, I had a hard time coming up with unit-tests covering this.
Motivation: https://reviews.llvm.org/D74735#2370909

Reviewed By: NoQ

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

Traverse-ignore explicit template instantiations

Continue to dump and match on explicit template specializations, but
omit explicit instantiation declarations and definitions.

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

[Arm][MC] Remove unused prefixes in .arch_extension fp tests

idiv: There is no difference between Armv7m and Thumbv7M
behaviour so the specific CHECKs are not needed.
The errors for Armv7-a and Thumbv7-a will always
include "ARM" or "THUMB" respectively so they need their
own CHECK prefix, making CHECK-V7 redundant.

mp: Behaviour is dependent on whether the triple is v6/v7/v7M
regardless of being Arm or Thumb. So we don't need the more
specific CHECK-ARMv7M etc.

simd: Errors are either v7 only, or v7 and v8 so CHECK-V8
is not needed.

fp: Same as simd

Reviewed By: ostannard

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

[libc++] Try fixing the oss-fuzz build

See https://github.com/google/oss-fuzz/issues/4586.

[AMDGPU] Run exp tests on GFX9 and GFX10 too. NFC.

[NFC][InstCombine] Update few comment updates i missed in 0ac56e8eaaeb

As pointed out in post-commit review in that commit

llvm.coro.id.async lowering: Parameterize how-to restore the current's continutation context and restart the pipeline after splitting

The `llvm.coro.suspend.async` intrinsic takes a function pointer as its
argument that describes how-to restore the current continuation's
context from the context argument of the continuation function. Before
we assumed that the current context can be restored by loading from the
context arguments first pointer field (`first_arg->caller_context`).

This allows for defining suspension points that reuse the current
context for example.

Also:

llvm.coro.id.async lowering: Add llvm.coro.preprare.async intrinsic

Blocks inlining until after the async coroutine was split.

Also, change the async function pointer's context size position

   struct async_function_pointer {
     uint32_t relative_function_pointer_to_async_impl;
     uint32_t context_size;
   }

And make the position of the `async context` argument configurable. The
position is specified by the `llvm.coro.id.async` intrinsic.

rdar://70097093

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

[NVPTX] [TableGen] Use new features of TableGen to simplify and clarify.

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

[VE] Add v(m)regs to preserve_all reg mask

V(m)regs where defined before CSR_preserve_all was, add them now.

Reviewed By: kaz7

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

[Clang][AArch64] Remove unused prefix in constrained rounding test

This test was added in 7f38812d5b7e0fd5145e44d5ae831a67d782dca6
and all the other tests make use of the COMMONIR check. So I think
this was left in by mistake for this particular test.

Reviewed By: kpn

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

[NFC] Fix typo in comment.

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

[TableGen] Clarify text and fix errors in the Programmer's Reference

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

[lldb] [test] Avoid double negation in llgs/debugserver logic

Use positive logic (i.e. llgs_platform/debugserver_platform) for
indicating which platforms use the particular server variant.
Deduplicate the lists — it is rather expected that none of the platforms
using LLGS would use debugserver.

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

[VE][NFC] Refactor to support more than one calling conv

Prepare for supporting  different calling conventions by factoring out
things into CC-dependent selection functions (getParamCC, getReturnCC).

Reviewed By: kaz7

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

[debuginfo-tests] NFC: Move test that was committed to the wrong location

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

Allow running back-deployment testing against libc++abi

Summary:
Before this patch, we could only link against the back-deployment libc++abi
dylib. This patch allows linking against the just-built libc++abi, but
running against the back-deployment one -- just like we do for libc++.

Also, add XFAIL markup to flag expected errors.

[SLP] Also try to vectorize incoming values of PHIs .

Currently we do not consider incoming values of PHIs as roots for SLP
vectorization. This means we miss scenarios like the one in the test
case and PR47670.

It appears quite straight-forward to consider incoming values of PHIs as
roots for vectorization, but I might be missing something that makes
this problematic.

In terms of vectorized instructions, this applies to quite a few
benchmarks across MultiSource/SPEC2000/SPEC2006 on X86 with -O3 -flto

    Same hash: 185 (filtered out)
    Remaining: 52
    Metric: SLP.NumVectorInstructions

    Program                                        base    patch   diff
     test-suite...ProxyApps-C++/HPCCG/HPCCG.test     9.00   27.00  200.0%
     test-suite...C/CFP2000/179.art/179.art.test     8.00   22.00  175.0%
     test-suite...T2006/458.sjeng/458.sjeng.test    14.00   30.00  114.3%
     test-suite...ce/Benchmarks/PAQ8p/paq8p.test    11.00   18.00  63.6%
     test-suite...s/FreeBench/neural/neural.test    12.00   18.00  50.0%
     test-suite...rimaran/enc-3des/enc-3des.test    65.00   95.00  46.2%
     test-suite...006/450.soplex/450.soplex.test    63.00   89.00  41.3%
     test-suite...ProxyApps-C++/CLAMR/CLAMR.test   177.00  250.00  41.2%
     test-suite...nchmarks/McCat/18-imp/imp.test    13.00   18.00  38.5%
     test-suite.../Applications/sgefa/sgefa.test    26.00   35.00  34.6%
     test-suite...pplications/oggenc/oggenc.test   100.00  133.00  33.0%
     test-suite...6/482.sphinx3/482.sphinx3.test   103.00  134.00  30.1%
     test-suite...oxyApps-C++/miniFE/miniFE.test   169.00  213.00  26.0%
     test-suite.../Benchmarks/Olden/tsp/tsp.test    59.00   73.00  23.7%
     test-suite...TimberWolfMC/timberwolfmc.test   503.00  622.00  23.7%
     test-suite...T2006/456.hmmer/456.hmmer.test    65.00   79.00  21.5%
     test-suite...libquantum/462.libquantum.test    58.00   68.00  17.2%
     test-suite...ternal/HMMER/hmmcalibrate.test    84.00   98.00  16.7%
     test-suite...ications/JM/ldecod/ldecod.test   351.00  401.00  14.2%
     test-suite...arks/VersaBench/dbms/dbms.test    52.00   57.00   9.6%
     test-suite...ce/Benchmarks/Olden/bh/bh.test   118.00  128.00   8.5%
     test-suite.../Benchmarks/Bullet/bullet.test   6355.00 6880.00  8.3%
     test-suite...nsumer-lame/consumer-lame.test   480.00  519.00   8.1%
     test-suite...000/183.equake/183.equake.test   226.00  244.00   8.0%
     test-suite...chmarks/Olden/power/power.test   105.00  113.00   7.6%
     test-suite...6/471.omnetpp/471.omnetpp.test    92.00   99.00   7.6%
     test-suite...ications/JM/lencod/lencod.test   1173.00 1261.00  7.5%
     test-suite...0/253.perlbmk/253.perlbmk.test    55.00   59.00   7.3%
     test-suite...oxyApps-C/miniAMR/miniAMR.test    92.00   98.00   6.5%
     test-suite...chmarks/MallocBench/gs/gs.test   446.00  473.00   6.1%
     test-suite.../CINT2006/403.gcc/403.gcc.test   464.00  491.00   5.8%
     test-suite...6/464.h264ref/464.h264ref.test   998.00  1055.00  5.7%
     test-suite...006/453.povray/453.povray.test   5711.00 6007.00  5.2%
     test-suite...FreeBench/distray/distray.test   102.00  107.00   4.9%
     test-suite...:: External/Povray/povray.test   4184.00 4378.00  4.6%
     test-suite...DOE-ProxyApps-C/CoMD/CoMD.test   112.00  117.00   4.5%
     test-suite...T2006/445.gobmk/445.gobmk.test   104.00  108.00   3.8%
     test-suite...CI_Purple/SMG2000/smg2000.test   789.00  819.00   3.8%
     test-suite...yApps-C++/PENNANT/PENNANT.test   233.00  241.00   3.4%
     test-suite...marks/7zip/7zip-benchmark.test   417.00  428.00   2.6%
     test-suite...arks/mafft/pairlocalalign.test   627.00  643.00   2.6%
     test-suite.../Benchmarks/nbench/nbench.test   259.00  265.00   2.3%
     test-suite...006/447.dealII/447.dealII.test   4641.00 4732.00  2.0%
     test-suite...lications/ClamAV/clamscan.test   106.00  108.00   1.9%
     test-suite...CFP2000/177.mesa/177.mesa.test   1639.00 1664.00  1.5%
     test-suite...oxyApps-C/RSBench/rsbench.test    66.00   65.00  -1.5%
     test-suite.../CINT2000/252.eon/252.eon.test   3416.00 3444.00  0.8%
     test-suite...CFP2000/188.ammp/188.ammp.test   1846.00 1861.00  0.8%
     test-suite.../CINT2000/176.gcc/176.gcc.test   152.00  153.00   0.7%
     test-suite...CFP2006/444.namd/444.namd.test   3528.00 3544.00  0.5%
     test-suite...T2006/473.astar/473.astar.test    98.00   98.00   0.0%
     test-suite...frame_layout/frame_layout.test    NaN     39.00   nan%

On ARM64, there appears to be a slight regression on SPEC2006, which
might be interesting to investigate:

   test-suite...T2006/473.astar/473.astar.test   0.9%

Reviewed By: ABataev

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

[lld testing] Unbreak read-only source builds

Tests must not modify the source tree.

[InstCombine] Regenerate narrow-math.ll tests