Reland "[CMake] Bumps minimum version to 3.20.0."

All build bots should be updated now.

This reverts commit 44d38022ab29a3156349602733b3459df5beef93.

[VPlan] Assert instead of check if VF is vector when widening GEPs(NFC)

VPWidenGEPRecipe should not be generated for scalar VFs. Replace
check with an assert.

Revert "[2a/3][ASan][libcxx] std::deque annotations"

https://lab.llvm.org/buildbot/#/builders/168/builds/13310
https://lab.llvm.org/buildbot/#/builders/239/builds/2107

This reverts commit 9a5f283139201ba5878780c06c97e4ad1f5eac39.

[clang-tidy] Modernize Handler (NFC)

[Vectorize] Use Densemap::contains (NFC)

[clangd] Replace None with std::nullopt in comments (NFC)

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

Revert "Give NullabilityKind a printing operator<<"

This reverts commit 0a532207b8696d81e46017f444bd2257347f129b.

This breaks several of our tests. Have given reproducers to author.
Reverting this until author can fix the issue.

[LoongArch] Provide basic TargetTransformInfo implementation

This patch only provides basic LoongArchTTIImpl, and more hooks
will be added to provide TTI machinery for LoongArch soon.

Reviewed By: SixWeining, xen0n

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

[C++20] [Modules] Don't check input files for C++20 Modules

Close https://github.com/llvm/llvm-project/issues/62269

Currently, the compiler will emit errors when we compile C++20 modules
if the referenced files changed or got removed. This is because we reuse
the existing logic from Clang implicit modules. It is helpful for clang
implicit modules since it is implicit and we want to be sure things
don't go wrong. But it is not necessary for C++20 modules. The C++20
modules is explicit and it is build systems' responsibility to maintain
the dependencies. So the check in the compiler side may be an overkill.

Fix a warning in D149117 [-Wunused-but-set-variable]

[gn] Move LoongArch target from llvm_all_experimental_targets to llvm_all_stable_targets

Reviewed By: SixWeining

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

[NFC][Clang] Fix static analyzer tool remarks about large copies by values in Format.cpp file

Reported by Static Analyzer Tool, Coverity:

Inside "Format.cpp" file, in clang::format::internal::reformat(clang::format::FormatStyle const &, llvm::StringRef, llvm::ArrayRef<clang::tooling::Range>, unsigned int, unsigned int, unsigned int, llvm::StringRef, clang::format::FormattingAttemptStatus *)::[lambda(clang::format::Environment const &) (instance 4)]::operator ()(clang::format::Environment const &): A very large function call parameter exceeding the high threshold is passed by value.

pass_by_value: Capturing variable S of type clang::format::FormatStyle (size 808 bytes) by value, which exceeds the high threshold of 512 bytes

This patch uses original code but with an init capture that does a move instead of a copy.

Reviewed By: tahonermann, erichkeane, MyDeveloperDay, owenpan, HazardyKnusperkeks

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

[LLDB] Add minimal support for the new Mojo language

Modular just announced a new language called Mojo. This patch adds an entry in the language list in LLDB for minimal support (e.g. being able to create a TypeSystem for this language). We will later add debug info entries when the language matures.

[MemProf] Create single version of helper function (NFC)

Small clean up to keep a single version of getAllocTypeAttributeString
which was duplicated locally.

[libc][docs] Fix incorrect CMake argument in GPU documentation

Summary;
This was changed a long time ago to drop the `LLVM_` prefix.

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

[llvm-profdata] ProfileReader cleanup - preparation for MD5 refactoring

Cleanup profile reader classes to prepare for complex refactoring as propsed in D147740 (Use MD5 as key for profile map). Change is too complicated so I am cleaning up the reader implementation first with these goals.
-  Reduce duplicated/similar logic
-  Reduce virtual functions, changing them to non-virtual
-  Reduce unnecessry checks, indirections, and dead writes.

This is patch 1/n. This patch refactors NameTable

Explaining several decisions here

1. useMD5() means whether  names of the profiles (the ProfileMap) are represented as MD5. It is NOT whether the input profile format is MD5. This function is an interface for IPO passes to decide whether to match function names or function MD5. There are two motives here:
(a) Eventually we want to use MD5 to represent all function contexts because it is much faster to use it as a key for lookup tables (prototype implementation D147740), so in compilation mode we call setProfileUseMD5() to force use MD5. While in tools mode (llvm-profdata) we want to keep the function name info if it's in the input profile.
(b) We also propose to allow multiple name tables and profile sections in ExtBinary format, and it could consist of name tables with or without using MD5, in this case MD5 prevails and other name tables are converted to MD5.

2. MD5 handling logic is pushed up to BinaryReader base class, because this trades a non-devirtualized virtual function call with a predictable branch. ReadStringFromTable() accounts for >5% time when loading a full 1 GB profile, it should not be virtual.

Reviewed By: davidxl

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

Fix MLIR Linalg Python test after adopting properties in f6ac7e3c6d5b

[test][sanitizer] Add feature for "any" GLIBC

"any" is actualy any resonably recent GLIBC.

[test][sanitizer] Add tests for join variants

Adopt Properties to store operations inherent Attributes in the Linalg dialect

This is part of an on-going migration to adopt Properties inside MLIR.

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

Fix UB passing nullptr to an EmptyProperties class when building OpAdaptor

A new forwarding constructor is introduced on the adaptor to take directly
an OpaqueProperties object and do the nullptr checking and casting to avoid
the boilerplate at callsites.

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

Add -misc-use-anonymous-namespace to .clang-tidy

This is at odds with the coding standard.
Quoting https://llvm.org/docs/CodingStandards.html#anonymous-namespaces
> Because of this, we have a simple guideline: make anonymous namespaces
> as small as possible, and only use them for class declarations.

Reviewed By: MaskRay

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

[MemProf] Context disambiguation cloning pass [patch 4/4]

Applies ThinLTO cloning decisions made during the thin link and
recorded in the summary index to the IR during the ThinLTO backend.

Depends on D141077.

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

Remove unused basic_android_tree/mipsel-linux-android

Reviewers: danalbert, enh, pirama, srhines

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

ms inline asm: recognize case-insensitive JMP and CALL as TargetLowering::C_Address

In a `__asm` block, a symbol reference is usually a memory constraint
(indirect TargetLowering::C_Memory) [LOOP]. CALL and JUMP instructions are special
that `__asm call k` can be an address constraint, if `k` is a function.

Clang always gives us indirect TargetLowering::C_Memory and need to convert it
to direct TargetLowering::C_Address. D133914 implements this conversion, but
does not consider JMP or case-insensitive CALL. This patch implements the missing
cases, so that `__asm jmp k` (`jmp ${0:P}`) will correctly lower to `jmp _k`
instead of `jmp dword ptr [_k]`.

(`__asm call k` lowered to `call dword ptr ${0:P}` and is fixed by D149695 to
lower to `call ${0:P}` instead.)

[LOOP]: Some instructions like LOOP{,E,NE} and Jcc always use an address
constraint (`loop _k` instead of `loop dword ptr [_k]`).

After this patch and D149579, all the following cases will be correct.
```
int k(int);
int (*kptr)(int);
...
__asm call k; // correct without this patch
__asm CALL k; // correct, but needs this patch to be compatible with D149579
__asm jmp k;  // correct, but needs this patch to be compatible with D149579
__asm call kptr; // will be fixed by D149579.  "Broken case" in clang/test/CodeGen/ms-inline-asm-functions.c
__asm jmp kptr;  // will be fixed by this patch and D149579
```

Reviewed By: pengfei

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

[lldb] Fix fallout from e9eaf7b430ee

Minor logic mistake. This caused TestObjCClassMethod to fail.

[test][lsan] Remove std::vector from test

[test][lsan] For thread args/result leak

[lldb] Migrate to GetPropertyAtIndexAs for ArchSpec (NFC)

Use the templated GetPropertyAtIndexAs helper for ArchSpec.

[lldb] Migrate to GetPropertyAtIndexAs for LanguageType (NFC)

Use the templated GetPropertyAtIndexAs helper for LanguageType.

[NFC] ][CLANG] Fix static code analyzer concerns

Reported by Coverity:

1. Inside "ASTReader.cpp" file,  in clang::ASTReader::FindExternalLexicalDecls(clang::DeclContext const *, llvm::function_ref<bool (clang::Decl::Kind)>, llvm::SmallVectorImpl<clang::Decl *> &): Using the auto keyword without an & causes a copy.

auto_causes_copy: Using the auto keyword without an & causes the copy of an object of type pair.

2. Inside "ASTReader.cpp" file, in clang::ASTReader::ReadAST(llvm::StringRef, clang::serialization::ModuleKind, clang::SourceLocation, unsigned int, llvm::SmallVectorImpl<clang::ASTReader::ImportedSubmodule> *): Using the auto keyword without an & causes a copy.

auto_causes_copy: Using the auto keyword without an & causes the copy of an object of type DenseMapPair.

3. Inside "CGOpenMPRuntimeGPU.cpp" file, in clang::CodeGen::CGOpenMPRuntimeGPU::emitGenericVarsEpilog(clang::CodeGen::CodeGenFunction &, bool): Using the auto keyword without an & causes a copy.

auto_causes_copy: Using the auto keyword without an & causes the copy of an object of type pair.

4. Inside "ASTWriter.cpp" file, in clang::ASTWriter::WriteHeaderSearch(clang::HeaderSearch const &): Using the auto keyword without an & causes a copy.

auto_causes_copy: Using the auto keyword without an & causes the copy of an object of type UnresolvedHeaderDirective.

Reviewed By: tahonermann

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

[bazel] Add missing dependency for b8e878da5c2ee65cc7a357890d83445625b59c79

Revert "[ArgumentPromotion] Bail if any callers are minsize"

This reverts commit 8b8466fd31e5a194fd8ba7a73a0f23d32f164318.

This is causing size regressions with -Oz and FullLTO. Revert while I
come up with a repro.

Revert "Reland [Pipeline] Don't limit ArgumentPromotion to -O3"

This reverts commit 6f29d1adf29820daae9ea7a01ae2588b67735b9e.

https://reviews.llvm.org/D149768 is causing size regressions for -Oz
with FullLTO, and I'm reverting that one while investigating. This
commit depends on that one, so it needs to be reverted as well.

Add myself as a code owner of SLP vectorizer + credits, NFC.

[libc++][PSTL] Make the PSTL available by default under -fexperimental-library

This removes the need for a custom libc++ build to have a basic set of PSTL algorithms.

Reviewed By: ldionne, #libc

Spies: miyuki, libcxx-commits, arichardson

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

[flang] OpenMP allocate directive parse tree fix

Addresses the same issue as the following abandoned revision: D104391.

Rewrite leading declarative allocations so they are nested within their respective executable allocate directive

Original:
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate

After rewriting:
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate

Reviewed By: kiranchandramohan

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

Co-authored-by: Isaac Perry <isaac.perry@arm.com>

Revert "[flang] OpenMP allocate directive parse tree fix"

This reverts commit 597d8563cd66f23d857196bf135a0c513115ece2.

Restore again "[MemProf] Context disambiguation cloning pass [patch 3/4]"

This reverts commit f09807ca9dda2f588298d8733e89a81105c88120, restoring
bfe7205975a63a605ff3faacd97fe4c1bf4c19b3 and follow on fix
e3e6bc699574550f2ed1de07f4e5bcdddaa65557, now that the nondeterminism
has been addressed by D149924.

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

[flang] OpenMP allocate directive parse tree fix

Addresses the same issue as the following abandoned revision: D104391.

Rewrite leading declarative allocations so they are nested within their respective executable allocate directive

Original:
```
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
```

After rewriting:
```
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
```

Co-authored-by: Isaac Perry <isaac.perry@arm.com>
Reviewed By: kiranchandramohan

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

Revert "[flang] OpenMP allocate directive parse tree fix"

This reverts commit 5faf45a3d24e603cbc8fe4eb45da386653dae5e5.
Once again arcanist stripped the co-author metadata.  I'm going to add it to the revision description and try one last time.

[clang][ci] Upload artifacts in a tarball to reduce size and avoid symlink issues

[flang] OpenMP allocate directive parse tree fix

Addresses the same issue as the following abandoned revision: D104391.

Rewrite leading declarative allocations so they are nested within their respective executable allocate directive

Original:
```
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
```

After rewriting:
```
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
```

Reviewed By: kiranchandramohan

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

Revert "[flang] OpenMP allocate directive parse tree fix"

This reverts commit eaf7d97865140a17f13ad77e5dc0216438127094.
Arcanist stripped co-author data from initial commit.

[RISCV][TTI] Model shuffle mask materialization with correct index type

We were modeling these as if the index type was always e8, but the actual
lowering uses the data type width if legal.  We also weren't accounting for
i64 on xlen32 correctly.

Noticed via inspection while working on the shuffle/buildvec lowering.  Note
that this costing is also wrong in a more major way - we don't actually use
a constant pool load in many cases.  But that's a separate issue.

[MC] Simplify flushPendingLabels. NFC

[flang][openacc] Lower host and device clauses to data operand ops

Update OpenACC update construct lowering to create
the data operand operations for host and device clauses.

Depends on D149909

Reviewed By: razvanlupusoru, jeanPerier

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

[mlir][openacc] Switch host/device clauses to data operand operations

Introduce acc.update_host and acc.update_device as data
operands operation to be used by the acc.update op.

Reviewed By: razvanlupusoru, jeanPerier

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

[NFC][CLANG] Fix nullptr dereference found by Coverity static analysis tool

Reported by Coverity:

  In clang::ASTContext::hasUniqueObjectRepresentations(clang::QualType, bool): Return value of function which returns null is dereferenced without checking.

  (Ty->isMemberPointerType()) {
       //returned_null: getAs returns nullptr.
       //var_assigned: Assigning: MPT = nullptr return value from getAs.
      const auto *MPT = Ty->getAs<MemberPointerType>();

     //dereference: Dereferencing a pointer that might be nullptr MPT when calling getMemberPointerInfo. (The virtual call resolves to
     <unnamed>::ItaniumCXXABI::getMemberPointerInfo.)
      return !ABI->getMemberPointerInfo(MPT).HasPadding;
    }

ABIs assume the parameter passed to `getMemberPointerInfo` is non-null.
This patch checks type by doing a `if (const auto *MPT = Ty->getAs<MemberPointerType>())` instead.

Reviewed By: erichkeane

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

[flang] OpenMP allocate directive parse tree fix

Addresses the same issue as the following abandoned revision: D104391.

Rewrite leading declarative allocations so they are nested within their respective executable allocate directive

Original:
```
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
```

After rewriting:
```
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
```

Reviewed By: kiranchandramohan

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

[libc] Make the RPC interfaces move only

This patch uses the changed interface in D149972 to make these classes
move-only. The `Port` class could be further refined to be
construct-only in a future patch, but for now this makes it more
difficult to misuse the interface.

Depends on D149972

Reviewed By: JonChesterfield

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

[libc] Rework 'cpp:optional' to support move construction

This patch replaces the existing `cpp::optional` type with a newer
version that has more features. This class is heavily inspired by the
old `llvm::Optional` class. Currently the limitations of this class is
that we only handle types with trivial constructors or operators.

Reviewed By: sivachandra

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

[mlir][linalg] Add support for folding pack(fill) into fill.

Reviewed By: qedawkins

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

[DAG] Rename computeOverflowKind -> computeOverflowForUnsignedAdd. NFC.

Matches the naming convention for the equivalent ValueTracking helpers - further SelectionDAG computeOverflowFor*() helpers will be added soon.

[DAG] expandIntMINMAX - add umax(x,1) --> sub(x,cmpeq(x,0)) fold

Move the fold from X86 to generic expansion

(We also have several existing expansions that are missing freezes on repeated operands - I've added a TODO for now).

Re-land "[lldb] Expose a const iterator for SymbolContextList"

Re-lands 04aa943be8ed5c03092e2a90112ac638360ec253 with modifications
to fix tests.
I originally reverted this because it caused a test to fail on Linux.
The problem was that I inverted a condition on accident.

[RISCV] Copy lack-of-signed-truncation-check.ll and signed-truncation-check.ll from AArch6/X86. NFC

This is a more exhaustive set of tests for the same issue D149814
is trying to solve.

[SLP][NFC]Add processBuildVector member function, NFC.

Introduce processBuildVector as a next step to generalize code for cost
estimation and code emission for gather/buildvector nodes.

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

ObjectFile: remove extraneous shadowed variable (NFCI)

We already construct the shared pointer for the module.  Avoid creating
a shadow copy and use the original definition.

Revert "[Flang] Change complex divide lowering"

This reverts commit 1b9d0deb6d53db760a91bcf63c9b2509f95af2bb.

Reverting since the signature of the called division functions is not
correct.

[VPlan] Assert instead checking if VF is vec when widening calls (NFC)

VPWidenCallRecipe should not be generated for scalar VFs. Replace check
with an assert.

[RISCV] Add scheduling information for Zba and Zbb to RISCVSchedSiFive7.td

Based on the following description from Andrew W.

Instructions not mentioned here behave the same as integer ALU ops
rev8 only executes in the late-A and late-B ALUs
shNadd[.uw] only execute on the early-B and late-B ALUs
clz[w], ctz[w], and orc.b and all rotates only execute in the late-B ALU
pcnt[w] looks exactly like integer multiply
This patch does not account for early/late ALU in the model. It is coded based
on the pipes only.

Co-Authored-By: topperc <craig.topper@sifive.com>
Differential Revision: https://reviews.llvm.org/D149497

Check if First argument in _builtin_assume_aligned_ is of pointer type

Currently clang doesn't verify if the first argument in
`_builtin_assume_aligned` is of pointer type. This leads to an
assertion build failure. This patch aims to add a check if the first
argument is of pointer type or not and diagnose it with
diag::err_typecheck_convert_incompatible if its not of pointer type.

Fixes https://github.com/llvm/llvm-project/issues/62305
Differential Revision: https://reviews.llvm.org/D149514

[flang][hlfir] Fixed array constructor lowering.

First issue is that the clean-ups were generated after the yield_element
operation that must be the terminator. Second issue is that codegen for
elemenal operation was not working properly with nested elemental ops.

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

[RISCV] Add X1 as implicit def of cm.jalt.

This instruction updates the RA register.

Reviewed By: VincentWu

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

[RISCV] Add DecoderNamespace to Zcmt instructions.

The Zcmt instructions overlap encoding space with some C extension
instructions. Isolate to a separate namespace.

Reviewed By: VincentWu

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

[Assignment Tracking] Skip scalable vectors in declare-to-assign pass

Do not convert dbg.declares to dbg.assigns for variables backed by scalable
vector allocas as this isn't yet supported.

Reviewed By: jmorse

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

[RISCV] Add sifive-x280 processor with all of its extensions

Add sifive-x280 processor that uses the SiFive7 scheduler model.

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

[SLP][NFC] Cleanup: Outline the code that vectorizes CmpInsts into a seaparate function.

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

[flang]Zero Initialize simple types

Instead of filling uninitialized global variables with "undef",
initialize them with 0. Only for Integer, Float or Logical type
variables. Complex, user defined data structures, arrays, etc
are not supported at this point.

This patch fixes the main problem of
https://github.com/llvm/llvm-project/issues/62432

Reviewed By: jeanPerier

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

[AArch64] Extend fp64 top zeroing peephole to all instructions

D147235 added a fold to remove instructions that zero the upper half of a
register if the instruction already implicitly zeros the register. As far as I
can tell this applies to all instructions that define a FPR64 register in
AArch64. This patch switches to a check for the register class. The full list
of instructions is:
  BSPv8i8
  FMOVD0
  ABSv1i64
  ABSv2i32
  ABSv4i16
  ABSv8i8
  ADDHNv2i64_v2i32
  ADDHNv4i32_v4i16
  ADDHNv8i16_v8i8
  ADDPv2i32
  ADDPv2i64p
  ADDPv4i16
  ADDPv8i8
  ADDv1i64
  ADDv2i32
  ADDv4i16
  ADDv8i8
  ANDv8i8
  BF16DOTlanev4bf16
  BFDOTv4bf16
  BICv2i32
  BICv4i16
  BICv8i8
  BIFv8i8
  BITv8i8
  BSLv8i8
  CLASTA_VPZ_D
  CLASTB_VPZ_D
  CLSv2i32
  CLSv4i16
  CLSv8i8
  CLZv2i32
  CLZv4i16
  CLZv8i8
  CMEQv1i64
  CMEQv1i64rz
  CMEQv2i32
  CMEQv2i32rz
  CMEQv4i16
  CMEQv4i16rz
  CMEQv8i8
  CMEQv8i8rz
  CMGEv1i64
  CMGEv1i64rz
  CMGEv2i32
  CMGEv2i32rz
  CMGEv4i16
  CMGEv4i16rz
  CMGEv8i8
  CMGEv8i8rz
  CMGTv1i64
  CMGTv1i64rz
  CMGTv2i32
  CMGTv2i32rz
  CMGTv4i16
  CMGTv4i16rz
  CMGTv8i8
  CMGTv8i8rz
  CMHIv1i64
  CMHIv2i32
  CMHIv4i16
  CMHIv8i8
  CMHSv1i64
  CMHSv2i32
  CMHSv4i16
  CMHSv8i8
  CMLEv1i64rz
  CMLEv2i32rz
  CMLEv4i16rz
  CMLEv8i8rz
  CMLTv1i64rz
  CMLTv2i32rz
  CMLTv4i16rz
  CMLTv8i8rz
  CMTSTv1i64
  CMTSTv2i32
  CMTSTv4i16
  CMTSTv8i8
  CNTv8i8
  DUPi64
  DUPv2i32gpr
  DUPv2i32lane
  DUPv4i16gpr
  DUPv4i16lane
  DUPv8i8gpr
  DUPv8i8lane
  EORv8i8
  EXTv8i8
  FABD64
  FABDv2f32
  FABDv4f16
  FABSDr
  FABSv2f32
  FABSv4f16
  FACGE64
  FACGEv2f32
  FACGEv4f16
  FACGT64
  FACGTv2f32
  FACGTv4f16
  FADDDrr
  FADDPv2f32
  FADDPv2i64p
  FADDPv4f16
  FADDv2f32
  FADDv4f16
  FCADDv2f32
  FCADDv4f16
  FCMEQ64
  FCMEQv1i64rz
  FCMEQv2f32
  FCMEQv2i32rz
  FCMEQv4f16
  FCMEQv4i16rz
  FCMGE64
  FCMGEv1i64rz
  FCMGEv2f32
  FCMGEv2i32rz
  FCMGEv4f16
  FCMGEv4i16rz
  FCMGT64
  FCMGTv1i64rz
  FCMGTv2f32
  FCMGTv2i32rz
  FCMGTv4f16
  FCMGTv4i16rz
  FCMLAv2f32
  FCMLAv4f16
  FCMLAv4f16_indexed
  FCMLEv1i64rz
  FCMLEv2i32rz
  FCMLEv4i16rz
  FCMLTv1i64rz
  FCMLTv2i32rz
  FCMLTv4i16rz
  FCSELDrrr
  FCVTASv1i64
  FCVTASv2f32
  FCVTASv4f16
  FCVTAUv1i64
  FCVTAUv2f32
  FCVTAUv4f16
  FCVTDHr
  FCVTDSr
  FCVTMSv1i64
  FCVTMSv2f32
  FCVTMSv4f16
  FCVTMUv1i64
  FCVTMUv2f32
  FCVTMUv4f16
  FCVTNSv1i64
  FCVTNSv2f32
  FCVTNSv4f16
  FCVTNUv1i64
  FCVTNUv2f32
  FCVTNUv4f16
  FCVTNv2i32
  FCVTNv4i16
  FCVTPSv1i64
  FCVTPSv2f32
  FCVTPSv4f16
  FCVTPUv1i64
  FCVTPUv2f32
  FCVTPUv4f16
  FCVTXNv2f32
  FCVTZSd
  FCVTZSv1i64
  FCVTZSv2f32
  FCVTZSv2i32_shift
  FCVTZSv4f16
  FCVTZSv4i16_shift
  FCVTZUd
  FCVTZUv1i64
  FCVTZUv2f32
  FCVTZUv2i32_shift
  FCVTZUv4f16
  FCVTZUv4i16_shift
  FDIVDrr
  FDIVv2f32
  FDIVv4f16
  FMADDDrrr
  FMAXDrr
  FMAXNMDrr
  FMAXNMPv2f32
  FMAXNMPv2i64p
  FMAXNMPv4f16
  FMAXNMv2f32
  FMAXNMv4f16
  FMAXPv2f32
  FMAXPv2i64p
  FMAXPv4f16
  FMAXv2f32
  FMAXv4f16
  FMINDrr
  FMINNMDrr
  FMINNMPv2f32
  FMINNMPv2i64p
  FMINNMPv4f16
  FMINNMv2f32
  FMINNMv4f16
  FMINPv2f32
  FMINPv2i64p
  FMINPv4f16
  FMINv2f32
  FMINv4f16
  FMLAL2lanev4f16
  FMLAL2v4f16
  FMLALlanev4f16
  FMLALv4f16
  FMLAv1i64_indexed
  FMLAv2f32
  FMLAv2i32_indexed
  FMLAv4f16
  FMLAv4i16_indexed
  FMLSL2lanev4f16
  FMLSL2v4f16
  FMLSLlanev4f16
  FMLSLv4f16
  FMLSv1i64_indexed
  FMLSv2f32
  FMLSv2i32_indexed
  FMLSv4f16
  FMLSv4i16_indexed
  FMOVDi
  FMOVDr
  FMOVXDr
  FMOVv2f32_ns
  FMOVv4f16_ns
  FMSUBDrrr
  FMULDrr
  FMULX64
  FMULXv1i64_indexed
  FMULXv2f32
  FMULXv2i32_indexed
  FMULXv4f16
  FMULXv4i16_indexed
  FMULv1i64_indexed
  FMULv2f32
  FMULv2i32_indexed
  FMULv4f16
  FMULv4i16_indexed
  FNEGDr
  FNEGv2f32
  FNEGv4f16
  FNMADDDrrr
  FNMSUBDrrr
  FNMULDrr
  FRECPEv1i64
  FRECPEv2f32
  FRECPEv4f16
  FRECPS64
  FRECPSv2f32
  FRECPSv4f16
  FRECPXv1i64
  FRINT32XDr
  FRINT32Xv2f32
  FRINT32ZDr
  FRINT32Zv2f32
  FRINT64XDr
  FRINT64Xv2f32
  FRINT64ZDr
  FRINT64Zv2f32
  FRINTADr
  FRINTAv2f32
  FRINTAv4f16
  FRINTIDr
  FRINTIv2f32
  FRINTIv4f16
  FRINTMDr
  FRINTMv2f32
  FRINTMv4f16
  FRINTNDr
  FRINTNv2f32
  FRINTNv4f16
  FRINTPDr
  FRINTPv2f32
  FRINTPv4f16
  FRINTXDr
  FRINTXv2f32
  FRINTXv4f16
  FRINTZDr
  FRINTZv2f32
  FRINTZv4f16
  FRSQRTEv1i64
  FRSQRTEv2f32
  FRSQRTEv4f16
  FRSQRTS64
  FRSQRTSv2f32
  FRSQRTSv4f16
  FSQRTDr
  FSQRTv2f32
  FSQRTv4f16
  FSUBDrr
  FSUBv2f32
  FSUBv4f16
  LASTA_VPZ_D
  LASTB_VPZ_D
  LD1Onev1d
  LD1Onev2s
  LD1Onev4h
  LD1Onev8b
  LD1Rv1d
  LD1Rv2s
  LD1Rv4h
  LD1Rv8b
  LDAPURdi
  LDNPDi
  LDPDi
  LDRDl
  LDRDroW
  LDRDroX
  LDRDui
  LDURDi
  MLAv2i32
  MLAv2i32_indexed
  MLAv4i16
  MLAv4i16_indexed
  MLAv8i8
  MLSv2i32
  MLSv2i32_indexed
  MLSv4i16
  MLSv4i16_indexed
  MLSv8i8
  MOVID
  MOVIv2i32
  MOVIv2s_msl
  MOVIv4i16
  MOVIv8b_ns
  MULv2i32
  MULv2i32_indexed
  MULv4i16
  MULv4i16_indexed
  MULv8i8
  MVNIv2i32
  MVNIv2s_msl
  MVNIv4i16
  NEGv1i64
  NEGv2i32
  NEGv4i16
  NEGv8i8
  NOTv8i8
  ORNv8i8
  ORRv2i32
  ORRv4i16
  ORRv8i8
  PMULv8i8
  RADDHNv2i64_v2i32
  RADDHNv4i32_v4i16
  RADDHNv8i16_v8i8
  RBITv8i8
  REV16v8i8
  REV32v4i16
  REV32v8i8
  REV64v2i32
  REV64v4i16
  REV64v8i8
  RSHRNv2i32_shift
  RSHRNv4i16_shift
  RSHRNv8i8_shift
  RSUBHNv2i64_v2i32
  RSUBHNv4i32_v4i16
  RSUBHNv8i16_v8i8
  SABAv2i32
  SABAv4i16
  SABAv8i8
  SABDv2i32
  SABDv4i16
  SABDv8i8
  SADALPv2i32_v1i64
  SADALPv4i16_v2i32
  SADALPv8i8_v4i16
  SADDLPv2i32_v1i64
  SADDLPv4i16_v2i32
  SADDLPv8i8_v4i16
  SADDLVv4i32v
  SCVTFSWDri
  SCVTFSXDri
  SCVTFUWDri
  SCVTFUXDri
  SCVTFd
  SCVTFv1i64
  SCVTFv2f32
  SCVTFv2i32_shift
  SCVTFv4f16
  SCVTFv4i16_shift
  SDOTlanev8i8
  SDOTv8i8
  SHADDv2i32
  SHADDv4i16
  SHADDv8i8
  SHLd
  SHLv2i32_shift
  SHLv4i16_shift
  SHLv8i8_shift
  SHRNv2i32_shift
  SHRNv4i16_shift
  SHRNv8i8_shift
  SHSUBv2i32
  SHSUBv4i16
  SHSUBv8i8
  SLId
  SLIv2i32_shift
  SLIv4i16_shift
  SLIv8i8_shift
  SMAXPv2i32
  SMAXPv4i16
  SMAXPv8i8
  SMAXv2i32
  SMAXv4i16
  SMAXv8i8
  SMINPv2i32
  SMINPv4i16
  SMINPv8i8
  SMINv2i32
  SMINv4i16
  SMINv8i8
  SQABSv1i64
  SQABSv2i32
  SQABSv4i16
  SQABSv8i8
  SQADDv1i64
  SQADDv2i32
  SQADDv4i16
  SQADDv8i8
  SQDMLALi32
  SQDMLALv1i64_indexed
  SQDMLSLi32
  SQDMLSLv1i64_indexed
  SQDMULHv2i32
  SQDMULHv2i32_indexed
  SQDMULHv4i16
  SQDMULHv4i16_indexed
  SQDMULLi32
  SQDMULLv1i64_indexed
  SQNEGv1i64
  SQNEGv2i32
  SQNEGv4i16
  SQNEGv8i8
  SQRDMLAHv2i32
  SQRDMLAHv2i32_indexed
  SQRDMLAHv4i16
  SQRDMLAHv4i16_indexed
  SQRDMLSHv2i32
  SQRDMLSHv2i32_indexed
  SQRDMLSHv4i16
  SQRDMLSHv4i16_indexed
  SQRDMULHv2i32
  SQRDMULHv2i32_indexed
  SQRDMULHv4i16
  SQRDMULHv4i16_indexed
  SQRSHLv1i64
  SQRSHLv2i32
  SQRSHLv4i16
  SQRSHLv8i8
  SQRSHRNv2i32_shift
  SQRSHRNv4i16_shift
  SQRSHRNv8i8_shift
  SQRSHRUNv2i32_shift
  SQRSHRUNv4i16_shift
  SQRSHRUNv8i8_shift
  SQSHLUd
  SQSHLUv2i32_shift
  SQSHLUv4i16_shift
  SQSHLUv8i8_shift
  SQSHLd
  SQSHLv1i64
  SQSHLv2i32
  SQSHLv2i32_shift
  SQSHLv4i16
  SQSHLv4i16_shift
  SQSHLv8i8
  SQSHLv8i8_shift
  SQSHRNv2i32_shift
  SQSHRNv4i16_shift
  SQSHRNv8i8_shift
  SQSHRUNv2i32_shift
  SQSHRUNv4i16_shift
  SQSHRUNv8i8_shift
  SQSUBv1i64
  SQSUBv2i32
  SQSUBv4i16
  SQSUBv8i8
  SQXTNv2i32
  SQXTNv4i16
  SQXTNv8i8
  SQXTUNv2i32
  SQXTUNv4i16
  SQXTUNv8i8
  SRHADDv2i32
  SRHADDv4i16
  SRHADDv8i8
  SRId
  SRIv2i32_shift
  SRIv4i16_shift
  SRIv8i8_shift
  SRSHLv1i64
  SRSHLv2i32
  SRSHLv4i16
  SRSHLv8i8
  SRSHRd
  SRSHRv2i32_shift
  SRSHRv4i16_shift
  SRSHRv8i8_shift
  SRSRAd
  SRSRAv2i32_shift
  SRSRAv4i16_shift
  SRSRAv8i8_shift
  SSHLv1i64
  SSHLv2i32
  SSHLv4i16
  SSHLv8i8
  SSHRd
  SSHRv2i32_shift
  SSHRv4i16_shift
  SSHRv8i8_shift
  SSRAd
  SSRAv2i32_shift
  SSRAv4i16_shift
  SSRAv8i8_shift
  SUBHNv2i64_v2i32
  SUBHNv4i32_v4i16
  SUBHNv8i16_v8i8
  SUBv1i64
  SUBv2i32
  SUBv4i16
  SUBv8i8
  SUDOTlanev8i8
  SUQADDv1i64
  SUQADDv2i32
  SUQADDv4i16
  SUQADDv8i8
  TBLv8i8Four
  TBLv8i8One
  TBLv8i8Three
  TBLv8i8Two
  TBXv8i8Four
  TBXv8i8One
  TBXv8i8Three
  TBXv8i8Two
  TRN1v2i32
  TRN1v4i16
  TRN1v8i8
  TRN2v2i32
  TRN2v4i16
  TRN2v8i8
  UABAv2i32
  UABAv4i16
  UABAv8i8
  UABDv2i32
  UABDv4i16
  UABDv8i8
  UADALPv2i32_v1i64
  UADALPv4i16_v2i32
  UADALPv8i8_v4i16
  UADDLPv2i32_v1i64
  UADDLPv4i16_v2i32
  UADDLPv8i8_v4i16
  UADDLVv4i32v
  UCVTFSWDri
  UCVTFSXDri
  UCVTFUWDri
  UCVTFUXDri
  UCVTFd
  UCVTFv1i64
  UCVTFv2f32
  UCVTFv2i32_shift
  UCVTFv4f16
  UCVTFv4i16_shift
  UDOTlanev8i8
  UDOTv8i8
  UHADDv2i32
  UHADDv4i16
  UHADDv8i8
  UHSUBv2i32
  UHSUBv4i16
  UHSUBv8i8
  UMAXPv2i32
  UMAXPv4i16
  UMAXPv8i8
  UMAXv2i32
  UMAXv4i16
  UMAXv8i8
  UMINPv2i32
  UMINPv4i16
  UMINPv8i8
  UMINv2i32
  UMINv4i16
  UMINv8i8
  UQADDv1i64
  UQADDv2i32
  UQADDv4i16
  UQADDv8i8
  UQRSHLv1i64
  UQRSHLv2i32
  UQRSHLv4i16
  UQRSHLv8i8
  UQRSHRNv2i32_shift
  UQRSHRNv4i16_shift
  UQRSHRNv8i8_shift
  UQSHLd
  UQSHLv1i64
  UQSHLv2i32
  UQSHLv2i32_shift
  UQSHLv4i16
  UQSHLv4i16_shift
  UQSHLv8i8
  UQSHLv8i8_shift
  UQSHRNv2i32_shift
  UQSHRNv4i16_shift
  UQSHRNv8i8_shift
  UQSUBv1i64
  UQSUBv2i32
  UQSUBv4i16
  UQSUBv8i8
  UQXTNv2i32
  UQXTNv4i16
  UQXTNv8i8
  URECPEv2i32
  URHADDv2i32
  URHADDv4i16
  URHADDv8i8
  URSHLv1i64
  URSHLv2i32
  URSHLv4i16
  URSHLv8i8
  URSHRd
  URSHRv2i32_shift
  URSHRv4i16_shift
  URSHRv8i8_shift
  URSQRTEv2i32
  URSRAd
  URSRAv2i32_shift
  URSRAv4i16_shift
  URSRAv8i8_shift
  USDOTlanev8i8
  USDOTv8i8
  USHLv1i64
  USHLv2i32
  USHLv4i16
  USHLv8i8
  USHRd
  USHRv2i32_shift
  USHRv4i16_shift
  USHRv8i8_shift
  USQADDv1i64
  USQADDv2i32
  USQADDv4i16
  USQADDv8i8
  USRAd
  USRAv2i32_shift
  USRAv4i16_shift
  USRAv8i8_shift
  UZP1v2i32
  UZP1v4i16
  UZP1v8i8
  UZP2v2i32
  UZP2v4i16
  UZP2v8i8
  XTNv2i32
  XTNv4i16
  XTNv8i8
  ZIP1v2i32
  ZIP1v4i16
  ZIP1v8i8
  ZIP2v2i32
  ZIP2v4i16
  ZIP2v8i8

[SLP][NFC]Add/use gather and createFreeeze member functions in
ShuffleInstructionBuilder, NFC.

[2a/3][ASan][libcxx] std::deque annotations

This revision is a part of a series of patches extending AddressSanitizer C++ container overflow detection capabilities by adding annotations, similar to those existing in std::vector, to std::string and `std::deque` collections. These changes allow ASan to detect cases when the instrumented program accesses memory which is internally allocated by the collection but is still not in-use (accesses before or after the stored elements for `std::deque`, or between the size and capacity bounds for `std::string`).

The motivation for the research and those changes was a bug, found by Trail of Bits, in a real code where an out-of-bounds read could happen as two strings were compared via a std::equals function that took `iter1_begin`, `iter1_end`, `iter2_begin` iterators (with a custom comparison function). When object `iter1` was longer than `iter2`, read out-of-bounds on `iter2` could happen. Container sanitization would detect it.

This revision introduces annotations for `std::deque`. Each chunk of the container can now be annotated using the `__sanitizer_annotate_double_ended_contiguous_container` function, which was added in the rG1c5ad6d2c01294a0decde43a88e9c27d7437d157. Any attempt to access poisoned memory will trigger an ASan error. Although false negatives are rare, they are possible due to limitations in the ASan API, where a few (usually up to 7) bytes before the container may remain unpoisoned. There are no false positives in the same way as with `std::vector` annotations.

This patch only supports objects (deques) that use the standard allocator. However, it can be easily extended to support all allocators, as suggested in the D146815 revision.

Furthermore, the patch includes the addition of the `is_double_ended_contiguous_container_asan_correct` function to libcxx/test/support/asan_testing.h. This function can be used to verify whether a `std::deque` object has been correctly annotated.

Finally, the patch extends the unit tests to verify ASan annotations (added LIBCPP_ASSERTs).
If a program is compiled without ASan, all helper functions will be no-ops. In binaries with ASan, there is a negligible performance impact since the code from the change is only executed when the deque container changes in size and it’s proportional to the change. It is important to note that regardless of whether or not these changes are in use, every access to the container's memory is instrumented.

Reviewed By: #libc, philnik

Spies: mikhail.ramalho, Enna1, #sanitizers, philnik, libcxx-commits

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

[Analysis] Fix a warning

This patch fixes:

  llvm/lib/Analysis/ValueTracking.cpp:895:12: error: unused variable
  'BitWidth' [-Werror,-Wunused-variable]

Revert "[RISCV] Add sifive-x280 processor with all of its extensions"

Test still not working...

This reverts commit a11dfd0fe6b1c38495f7de9858a2d1839d2902b9.

[lldb] Use Haswell instead of arm64 in TestUniversal64

The architecture doesn't really matter for the test, at least not until
the dynamic loader can load these fat64 binaries. Use Hawell instead of
arm64 to support older bots that don't know about Apple Silicon triples.

[RISCV] Add sifive-x280 processor with all of its extensions

Add sifive-x280 processor that uses the SiFive7 scheduler model.

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

[AMDGPU] Also consider global and scratch instructions when flushing vmcnt counter in loop preheader

Reviewed By: foad

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

[lldb][TypeSystem] ForEach: Don't hold the TypeSystemMap lock across callback

The `TypeSystemMap::m_mutex` guards against concurrent modifications
of members of `TypeSystemMap`. In particular, `m_map`.

`TypeSystemMap::ForEach` iterates through the entire `m_map` calling
a user-specified callback for each entry. This is all done while
`m_mutex` is locked. However, there's nothing that guarantees that
the callback itself won't call back into `TypeSystemMap` APIs on the
same thread. This lead to double-locking `m_mutex`, which is undefined
behaviour. We've seen this cause a deadlock in the swift plugin with
following backtrace:

```

int main() {
    std::unique_ptr<int> up = std::make_unique<int>(5);

    volatile int val = *up;
    return val;
}

clang++ -std=c++2a -g -O1 main.cpp

./bin/lldb -o “br se -p return” -o run -o “v *up” -o “expr *up” -b
```

```
frame #4: std::lock_guard<std::mutex>::lock_guard
frame #5: lldb_private::TypeSystemMap::GetTypeSystemForLanguage <<<< Lock #2
frame #6: lldb_private::TypeSystemMap::GetTypeSystemForLanguage
frame #7: lldb_private::Target::GetScratchTypeSystemForLanguage
...
frame #26: lldb_private::SwiftASTContext::LoadLibraryUsingPaths
frame #27: lldb_private::SwiftASTContext::LoadModule
frame #30: swift::ModuleDecl::collectLinkLibraries
frame #31: lldb_private::SwiftASTContext::LoadModule
frame #34: lldb_private::SwiftASTContext::GetCompileUnitImportsImpl
frame #35: lldb_private::SwiftASTContext::PerformCompileUnitImports
frame #36: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetSwiftASTContext
frame #37: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetPersistentExpressionState
frame #38: lldb_private::Target::GetPersistentSymbol
frame #41: lldb_private::TypeSystemMap::ForEach                 <<<< Lock #1
frame #42: lldb_private::Target::GetPersistentSymbol
frame #43: lldb_private::IRExecutionUnit::FindInUserDefinedSymbols
frame #44: lldb_private::IRExecutionUnit::FindSymbol
frame #45: lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence
frame #46: lldb_private::IRExecutionUnit::MemoryManager::findSymbol
frame #47: non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol
frame #48: llvm::LinkingSymbolResolver::findSymbol
frame #49: llvm::LegacyJITSymbolResolver::lookup
frame #50: llvm::RuntimeDyldImpl::resolveExternalSymbols
frame #51: llvm::RuntimeDyldImpl::resolveRelocations
frame #52: llvm::MCJIT::finalizeLoadedModules
frame #53: llvm::MCJIT::finalizeObject
frame #54: lldb_private::IRExecutionUnit::ReportAllocations
frame #55: lldb_private::IRExecutionUnit::GetRunnableInfo
frame #56: lldb_private::ClangExpressionParser::PrepareForExecution
frame #57: lldb_private::ClangUserExpression::TryParse
frame #58: lldb_private::ClangUserExpression::Parse
```

Our solution is to simply iterate over a local copy of `m_map`.

**Testing**

* Confirmed on manual reproducer (would reproduce 100% of the time
  before the patch)

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

Revert "[RISCV] Add sifive-x280 processor with all of its extensions"

This commit causes tests to fail.

This reverts commit 55e196e7718c543b4492f2949c13de003a4ba443.

[SLP][NFC]Add remark output to the test with the perfect diamond match
in vectorbuild nodes, NFC.

[WebAssembly] Mark @llvm.wasm.shuffle lane indices as immediates

This intrinsic is meant to lower directly to the i8x16.shuffle instruction,
which takes its lane index arguments as immmediates. The ISel for the intrinsic
assumed that the lane index arguments were constants, so bitcode that
"incorrectly" used this intrinsic with non-immediate arguments caused an
assertion failure in the backend.

Avoid the crash by defining the lane index arguments to be immediates, matching
the underlying instruction. Update ISel accordingly. This change means that the
bitcode that previously caused a crash will now fail to validate.

Fixes #55559.

Reviewed By: dschuff

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

[libc] Support concurrent RPC port access on the GPU

Previously we used a single port to implement the RPC. This was
sufficient for single threaded tests but can potentially cause deadlocks
when using multiple threads. The reason for this is that GPUs make no
forward progress guarantees. Therefore one group of threads waiting on
another group of threads can spin forever because there is no guarantee
that the other threads will continue executing. The typical workaround
for this is to allocate enough memory that a sufficiently large number
of work groups can make progress. As long as this number is somewhat
close to the amount of total concurrency we can obtain reliable
execution around a shared resource.

This patch enables using multiple ports by widening the arrays to a
predetermined size and indexes into them. Empty ports are currently
obtained via a trivial linker scan. This should be imporoved in the
future for performance reasons. Portions of D148191 were applied to
achieve parallel support.

Depends on D149581

Reviewed By: JonChesterfield

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

AMDGPU: Reserve 0x048, 0x049, 0x04a MACHs

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

Revert "[RISCV] Add scheduling information for Zba and Zbb to RISCVSchedSiFive7.td"

This commit was merged incorrectly.

This reverts commit cd02b69e75dd677acdc6c77e6b7bb8d02099b7c0.

[scudo] Fix missing one block in range marking

When a range contains only one block, we may not mark the pages touched
by the block as can-be-released. This happens in the last group and if
it only contains single block.

Also enhance the existing tests and add a new test for testing the last
block.

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

[RISCV] Add Scheduling information for Zfh to SiFive7 model

Everything is the same as F extension, except sqrt and div are 13
cycles faster.

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

[RISCV] Add scheduling information for Zba and Zbb to RISCVSchedSiFive7.td

Based on the following description from Andrew W.

- Instructions not mentioned here behave the same as integer ALU ops
- rev8 only executes in the late-A and late-B ALUs
- shNadd[.uw] only execute on the early-B and late-B ALUs
- clz[w], ctz[w], and orc.b and all rotates only execute in the late-B ALU
- pcnt[w] looks exactly like integer multiply

This patch does not account for early/late ALU in the model. It is coded based
on the pipes only.

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

Co-Authored-By: topperc <craig.topper@sifive.com>

[RISCV] Add sifive-x280 processor with all of its extensions

Add sifive-x280 processor that uses the SiFive7 scheduler model.

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

[NFC][Clang] Remove release note since the patch was backported in time

SymbolFile: invert condition, remove unnecessary `else` (NFC)

Remove an unnecessary `else` condition and swap the condition to be
positive rather than negative to make simpler to follow.  NFC

[DAG] Add TargetLowering::expandABD and convert X86 lowering to use it

Scalar widening cases are still custom lowered in the X86 backend - we still need to add promotion/legalization support to handle these

[AArch64] Tests for implicit zero patterns. NFC

See D149616

[MemProf] Use MapVector to avoid non-determinism

Multiple cases of instability in the cloning behavior occurred due to
iteration of maps indexed by pointers. Fix by changing the maps to
MapVector. This necessitated adding DenseMapInfo specializations for the
structure types used in the keys.

These were found while trying to commit patch 3 of the cloning
(bfe7205975a63a605ff3faacd97fe4c1bf4c19b3), but the second one turned
out to be in code committed in patch 2, but just exposed by a new test
added with patch 3. Specifically, the iteration in identifyClones().

Added the portion of the new test cases from patch 3 that only relied on
the already committed changes and exposed the issue.

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

[AArch64] Handle vector with two different values

If vector has two different values and it can be splitted into two sub
vectors with same length, generate two DUP and CONCAT_VECTORS/VECTOR_SHUFFLE.
For example,

 t22: v16i8 = BUILD_VECTOR t23, t23, t23, t23, t23, t23, t23, t23,
                           t24, t24, t24, t24, t24, t24, t24, t24
==>
   t26: v8i8 = AArch64ISD::DUP t23
   t28: v8i8 = AArch64ISD::DUP t24
 t29: v16i8 = concat_vectors t26, t28

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

[AArch64] Emit FNMADD instead of FNEG(FMADD)

Emit FNMADD instead of FNEG(FMADD) for optimization levels
above Oz when fast-math flags (nsz+contract) permit it.

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

[mlir][transform] Clean up SplitHandlesOp

* Rename to `SplitHandleOp`: it splits a single handle.
* Drop `num_result_handles` attribute: it is redundant and can be inferred from the number of results.
* Improve documentation and minor code cleanups.

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

[Flang] Change complex divide lowering

Currently complex division is lowered to a fir.divc operation and the
fir.divc is later converted to a sequence of llvm operations to perform
complex division, however this causes issues for extreme values when
the calculations overflow.

This patch changes the lowering of complex division to use the Intrinsic
Call functionality to lower into library calls (for single, double,
extended and quad precisions) or an MLIR complex dialect division operation
(for half and bfloat precisions).

Note 1: If the Complex To Standard conversion of division operation
matures then we can use it for all precisions. Currently it has the
same issues as the conversion of fir.divc.
Note 2: A previous patch (D145808) did the same but during conversion of
the fir.divc operation. But using function calls at that stage leads to
ABI issues since the conversion to LLVM is not aware of the complex target
rewrite.
Note 3: If the patch is accepted, fir.divc can be removed from FIR.

Reviewed By: vzakhari, PeteSteinfeld, DavidTruby

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

[clang][RISCV] Set HasLegalHalfType to true if zfh is enabled

The desired semantics for HasLegalHalfType are slightly unclear in that
the comment for HasLegalHalfType says "True if the backend supports
operations on the half LLVM IR type." Which operations? We get very
limited scalar operations with zfhmin, more with zfh, and vector support
with zvfh. While the comment for hasLegalHalfType() says "Determine
whether _Float16 is supported on this target."

This patch sets HasLegalHalfType to true for zfh.

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

[clang][test][RISCV] Pre-commit test for HasLegalHalfType patch

This test captures the codegen difference of D145071.