This patch implements P0674R1, i.e. support for arrays in std::make_shared
and std::allocate_shared.

Co-authored-by: Zoe Carver <z.zoelec2@gmail.com>

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

```
{X86::MOVLHPSrr,X86::MOVHPSrm}
{X86::VMOVLHPSZrr,X86::VMOVHPSZ128rm}
{X86::VMOVLHPSrr,X86::VMOVHPSrm}
```

Each of the three pairs has different mnemonic, so we have to add it
manually. This is a follow-up patch for D122477.

[TLI] `TargetLowering::SimplifyDemandedVectorElts()`: narrowing bitcast: fill known zero elts from known src bits

E.g. in
```
%i0 = zext <2 x i8> to <2 x i16>
%i1 = bitcast <2 x i16> to <4 x i8>
```
the `%i0`'s zero bits are known to be `0xFF00` (upper half of every element is known zero),
but no elements are known to be zero, and for `%i1`, we don't know anything about zero bits,
but the elements under `0b1010` mask are known to be zero (i.e. the odd elements).

But, we didn't perform such a propagation.

Noticed while investigating more aggressive `vpmaddwd` formation.

Reviewed By: RKSimon

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

Place PersistentId declaration under #if LLVM_ENABLE_ABI_BREAKING_CHECKS to
reduce memory usage when it is not needed.

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

It appears that the DialectRegistry::addExtension template was never
instantiated because it contains an obvious compilation error. Fix it.

Reviewed By: nicolasvasilache

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

Add specific dates and versions to note about source_location handling.

Reviewed By: aaron.ballman

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

Variable locations now come in two modes, instruction referencing and
DBG_VALUE. At -O0 we pick DBG_VALUE to allow fast construction of variable
information. Unfortunately, SelectionDAG edits the optimisation level in
the presence of opt-bisect-limit, meaning different passes have different
views of what variable location mode we should use. That causes assertions
when they're mixed.

This patch plumbs through a boolean in SelectionDAG from start to
instruction emission, so that we don't rely on the current optimisation
level for correctness.

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

This simplifies completeness comparisons against OpenCLBuiltins.td and
also makes the header no longer "claim" the argument name identifiers.

Continues the direction set out in D119560.

This reverts commit 96e9b6c9.

Add support for i386, s390x in Triple::getArchTypeForLLVMName.

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

* replace virtual with override
* use default like in full code example

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

As raised on PR52267, XOR(X,MIN_SIGNED_VALUE) can be treated as ADD(X,MIN_SIGNED_VALUE), so let these cases use the 'AddLike' folds, similar to how we perform no-common-bits OR(X,Y) cases.

define i8 @src(i8 %x) {
  %r = xor i8 %x, 128
  ret i8 %r
}
=>
define i8 @tgt(i8 %x) {
  %r = add i8 %x, 128
  ret i8 %r
}
Transformation seems to be correct!

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

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

* Store bbArg indices instead of BlockArguments, so that args can be changed during bufferizationn.
* Use type aliases for better readability.

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

```
X86::MMX_MOVD64from64rr -> X86::MMX_MOVQ64mr
X86::MMX_MOVD64grr -> X86::MMX_MOVD64mr
```

These two entries were added in llvm-svn: 372770.
I think these two should be reversable.

Reviewed By: RKSimon, pengfei

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

https://reviews.llvm.org/D122641 introduced fixes to the ExpandShapeOp verifier
but also introduced an artificial layout limitation that prevents the consideration of transposed layouts.

This revision fixes the omissions and reimplements the logic using saturated arithmetic which is more
idiomatic and avoids leaking internal implementation details.

Tests cases are added for transposed layouts.

Reviewed By: springerm

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

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

Remove limitation that wouldn't perform the fold if all the inverted bits are known zero

The thumb2 changes look to be benign, although it does show that the TEQ/TST isel patterns could probably be improved.

Fixes movmsk regression in D122754

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

Or rather, error out if it is set to something other than ON. This
removes the ability to enable the legacy pass manager by default,
but does not remove the ability to explicitly enable it through
various flags like -flegacy-pass-manager or -enable-new-pm=0.

I checked, and our test suite definitely doesn't pass with
LLVM_ENABLE_NEW_PASS_MANAGER=OFF anymore.

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

This is useful when building a complete toolchain to ensure that CRT
is built after builtins but before the rest of the compiler-rt.

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

For now, just support atomic operations by libcall. Further, should investigate atomic
implementation in CSKY target and codegen with atomic and fence related instructions.

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

Add void casts to mark the variables used, next to the places where
they are used in assert or `LLVM_DEBUG()` expressions.

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

This reverts commit b89b18e3 since
it broke the sanitizer bots.

This is useful when building a complete toolchain to ensure that CRT
is built after builtins but before the rest of the compiler-rt.

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

Intuitively, the memory folding pair should have the same mnemonic.

This patch removes
```
{X86::SENDUIPI,X86::VMXON}
```
in the auto-generated table.
And `NotMemoryFoldable` for `TPAUSE` and `CLWB` can be saved.
```
{X86::MOVLHPSrr,X86::MOVHPSrm}
{X86::VMOVLHPSZrr,X86::VMOVHPSZ128rm}
{X86::VMOVLHPSrr,X86::VMOVHPSrm}
```
It seems the three pairs above are mistakenly killed.
But we can add them back manually later.

Reviewed By: Amir

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

[Support/Hash functions] Change the `final()` and `result()` of the hashing functions to return an array of bytes

Returning `std::array<uint8_t, N>` is better ergonomics for the hashing functions usage, instead of a `StringRef`:

* When returning `StringRef`, client code is "jumping through hoops" to do string manipulations instead of dealing with fixed array of bytes directly, which is more natural
* Returning `std::array<uint8_t, N>` avoids the need for the hasher classes to keep a field just for the purpose of wrapping it and returning it as a `StringRef`

As part of this patch also:

* Introduce `TruncatedBLAKE3` which is useful for using BLAKE3 as the hasher type for `HashBuilder` with non-default hash sizes.
* Make `MD5Result` inherit from `std::array<uint8_t, 16>` which improves & simplifies its API.

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

By specification, source and destination of llvm.memcpy.* must either be equal or non-overlapping. This semantics is hard or impossible to figure out once lowered. This patch explicitly marks loads from source and stores to destination as not aliasing if source and destination is known to be not equal.

Reviewed By: arsenm

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

The Attributor, as many other parts in LLVM, uses pointer equivalence
for `llvm::Value`s. This only works as long as `llvm::Value`s are
dynamically unique, or, to be exact, we will never end up with the same
`llvm::Value` representing two dynamic instances. We already provided a
helper to check the former, namely `AA::isDynamicallyUnique`, however we
could not check the latter. In this patch we move the logic into a
separate AA which helps with the growing complexity and use cases. We
also extend the interface to answer the second question rather than the
first. So we do not determine dynamically uniqueness but if we might end
up with the `llvm::Value` describing a different dynamic instance. Note
that the latter is very much tied to the Attributor capabilities to look
through memory, recursion, etc. so we need to update the logic as we go.

If a load is only used by an `llvm.assume` and the stores feeding into
the load are not removable, keep the load.

Add CSKY target toolchains to support csky in linux and elf environment.

It can leverage the basic universal Linux toolchain for linux environment, and only add some compile or link parameters.
For elf environment, add a CSKYToolChain to support compile and link.

Also add some parameters into basic codebase of clang driver.

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

Reviewed By: frasercrmck

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