The PowerPC fix landed in d9069dd9. This is in preparation for D98931.

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

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

Commit 6bc1e69d changed the search string
to also check for the generated strings that surround the plain assert:

    Assertion `false && "lldb-test assert"' failed
                                         ^^^^^^^^^

This causes the test to fail on setups where the generated assert message
looks different. E.g., on macOS the generated message looks like this:

    Assertion failed: (false && "lldb_assert failed"), function lldb_assert

This reverts the old behaviour of just checking for the actual string we
have inside LLDB.

Add a new clone operation to the memref dialect. This operation implicitly
copies data from a source buffer to a new buffer. In contrast to the linalg.copy
operation, this operation does not accept a target buffer as an argument.
Instead, this operation performs a conceptual allocation which does not need to
be performed manually.

Furthermore, this operation resolves the dependency from the linalg-dialect
in the BufferDeallocation pass. In addition, we also extended the canonicalization
patterns to fold clone operations. The copy removal pass has been removed.

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

This extends the recent MVE lane interleaving passto handle other
non-instruction leaves, for which a new shuffle is added. This helps
especially for constants and potentially for arguments.

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

This patch folds the following pattern:

```
%arg0 = ...
%0 = sexti %arg0 : i1 to i8
%1 = trunci %0 : i8 to i1
```

into just `%arg0`.

Reviewed By: mehdi_amini

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

LLDB on Linux built with symbols is showing this error.
Without symbols it still PASSes:
  lldb-test: .../lldb/source/Utility/LLDBAssert.cpp:29: void lldb_private::lldb_assert(bool, const char *, const char *, const char *, unsigned int): Assertion `false && "lldb_assert failed"' failed.

With symbols it FAILs:
  lldb-test: .../lldb/tools/lldb-test/lldb-test.cpp:1086: int opts::assert::lldb_assert(lldb_private::Debugger &): Assertion `false && "lldb-test assert"' failed.

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

LLVMOrcDisposeObjectLayer and LLVMOrcExecutionSessionGetJITDylibByName did not
have matching signatures between the C-API header and binding implementations.
Fixes http://llvm.org/PR49745.

Patch by Mats Larsen. Thanks Mats!

Reviewed by: lhames

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

This follows GCC and simplifies code. /usr/local/include and TOOL_INCLUDE_DIR
should not conflict with the resource directory include so users should not
observe any difference.

This can only happen if offset types that are larger than the
pointer size are involved. The previous implementation did not
assert in this case because it initialized the APInts to the
width of one of the variables -- though I strongly suspect it
did not compute correct results in this case.

Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32621
reported by fhahn.

For these cases we need to extract the upper or lower elements,
multiply them using 16-bit multiplies and repack them.

Previously we used punpcklbw/punpckhbw+psraw or pmovsxbw+pshudfd to
extract and sign extend so we could use pmullw to compute the 16-bit
product and then shift down the high bits.

We can avoid the need to sign extend if we unpack the bytes into
the high byte of each word and fill the lower byte with 0 using
pxor. This puts the sign bit of each byte into the sign bit of
each word. Since the LHS and RHS have 8 trailing zeros, the full
32-bit product of those 16-bit values will have 16 trailing zeros.
This means the 16-bit product of the original bytes is in the upper
16 bits which we can calculate using pmulhw.

Reviewed By: RKSimon

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

[X86][update_llc_test_checks] Use a less greedy regular expression for replacing constant pool labels in tests.

While working on D97208 I noticed that these greedy regular
expressions prevent tests from failing when (%rip) appears after
a constant pool label when it didn't before.

Reviewed By: RKSimon, pengfei

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

MVE does not have a single sext/zext or trunc instruction that takes the
bottom half of a vector and extends to a full width, like NEON has with
MOVL. Instead it is expected that this happens through top/bottom
instructions. So the MVE equivalent VMOVLT/B instructions take either
the even or odd elements of the input and extend them to the larger
type, producing a vector with half the number of elements each of double
the bitwidth. As there is no simple instruction for a normal extend, we
often have to expand sext/zext/trunc into a series of lane moves (or
stack loads/stores, which we do not do yet).

This pass takes vector code that starts at truncs, looks for
interconnected blobs of operations that end with sext/zext and
transforms them by adding shuffles so that the lanes are interleaved and
the MVE VMOVL/VMOVN instructions can be used. This is done pre-ISel so
that it can work across basic blocks.

This initial version of the pass just handles a limited set of
instructions, not handling constants or splats or FP, which can all come
as extensions to this base.

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

This follows GCC. Having libstdc++/libc++ include paths is not useful
anyway because libstdc++/libc++ header files cannot find features.h.

While here, suppress -stdlib++-isystem with -nostdlibinc.

[X86] Don't define vpclmulqdq or vaes intrinsics in the headers unless avx512fintrin.h has been included.

The intrinsics won't compile unless avx512fintrin.h has declared
the 512 bit types.

We don't yet use mulhsu, but we should.

This reverts commit 20d5c42e.

This is another step towards parity with cmp+select min/max idioms.

See D98152.

This reverts commit 4fefed65.
Broke check-clang everywhere.

RVV intrinsics has new overloading rule, please see
https://github.com/riscv/rvv-intrinsic-doc/commit/82aac7dad4c6c1c351ed5b17ca6007c395843ed7

Changed:
1. Rename `generic` to `overloaded` because the new rule is not using C11 generic.
2. Change HasGeneric to HasNoMaskedOverloaded because all masked operations
   support overloading api.
3. Add more overloaded tests due to overloading rule changed.

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

I think byval/sret and the others are close to being able to rip out
the code to support the missing type case. A lot of this code is
shared with inalloca, so catch this up to the others so that can
happen.

Breaking a string literal or a function calls arguments with
AlignConsecutiveDeclarations or AlignConsecutiveAssignments did misalign
the continued line. E.g.:

void foo() {
  int myVar = 5;
  double x  = 3.14;
  auto str  = "Hello"
            "World";
}

or

void foo() {
  int    myVar = 5;
  double x = 3.14;
  auto   str = "Hello"
             "World";
}

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

Adds more information about automated diagnostic reporting for statement
attributes and adds a bit more documentation about statement attributes
in general.

If the sizes of both memory locations are unknown, we can only
perform a check on the underlying objects. There's no point in
going through GEP decomposition in this case.

This patch adds a new isIntOrFPConstant  helper function to check if a
SDValue is a integer of FP constant. This pattern is used in various
places.

There also are places that incorrectly just check for integer constants,
e.g. D99384, so hopefully this helper will help people avoid that issue.

Reviewed By: RKSimon

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

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

s/LLDB Tests/LLDB tests/

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