This patch is to solve this:
    https://lab.llvm.org/buildbot#builders/36/builds/26801
Created by this patch: a20112a7

[AArch64]SME2 instructions that use ZTO operand

Having AllEnumtypes to be a vector of TrackingMDNodeRef makes it possible
to reflect changes in metadata in the vector if they took place before DIBuilder
being finalized.

Otherwise, we end up with heap-use-after-free because AllEnumTypes contains
metadata that no longer valid.

Consider a case where we have a class containing a definition of a enum,
so this enum has the class as a scope. For some reason (doesn't matter for
the current issue), we create a temporary debug metadata for this class, and
then resolve it while finalizing CGDebugInfo.

In the case of collision during uniqifying the temporary, we then need
to replace its uses with a new pointer. If a temporary's user is unique
(this is the enum mentioned above), we may need re-uniquefying it,
which may return a new pointer in the case of another collision.
If so, the pointer we stored in AllEnumTypes vector become dangling.
Making AllEnumTypes hodling TrackingMDNodeRef should solve this problem
(see debug-info-enum-metadata-collision.cpp test for details).

Reviewed By: dblaikie

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

Diffing phi nodes was recently added to llvm-diff.
However, there currently is a limitation where equivalent values
cannot be detected as such, leading to false positive diff reports.

If a phi node refers a value defined in a basic block dominated by
the current basic block, for example a phi node in a loop header referring
a value defined in the loop body, we cannot prove equivalence of the referred
values, because the basic block containing the variable definition has
not yet been processed.

This commit adds a test case showing this behavior, serving as a precommit
for an upcoming fix of the above.

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

Allows for better matching of VOP3 mods.

Reviewed By: arsenm

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

This reverts commit 957eed0b.

arm_neon_sve_bridge.h is not generated, so the rules which ensure the
generated files get copied into the installation prefix don't apply to
this one.

Add it to the aarch64_only_files set instead, which ensures it ends up
both in the build directory and the installation directory.

Tested with build targets `clang-resource-headers` and
`install-clang-resource-headers`.

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

As now errors in file operation are handled, check for file existence
must be done prior to check for recursion, otherwise reported errors are
misleading.

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

This patch adds the assembly/disassembly for the following instructions:
  ZERO (ZT0): Zero ZT0.
  LDR (ZT0): Load ZT0 register.
  STR (ZT0): Store ZT0 register.
  MOVT (scalar to ZT0): Move 8 bytes from general-purpose register to ZT0.
       (ZT0 to scalar): Move 8 bytes from ZT0 to general-purpose register.
 Consecutive:
   LUTI2 (single): Lookup table read with 2-bit indexes.
         (two registers): Lookup table read with 2-bit indexes.
         (four registers): Lookup table read with 2-bit indexes.
   LUTI4 (single): Lookup table read with 4-bit indexes.
         (two registers): Lookup table read with 4-bit indexes.
         (four registers): Lookup table read with 4-bit indexes.

The reference can be found here:

https://developer.arm.com/documentation/ddi0602/2022-09

This patch also adds a new register class and operand for zt0
and a another index operand uimm3s8

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

This reverts commit b756096b.
See regression https://github.com/llvm/llvm-project/issues/58774

This change-set defines the LoweringOptions the same way
other options are defined in Flang.

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

This patch fixes codegen for `[su]itofp` instructions.

In LoongArch, a legal int-to-float conversion is done in two steps:

1. Move the data from `GPR` to `FPR`. (FRLen >= GRLen)
2. Conversion in `FPR`. (the data in `FPR` is treated as a signed value)

Based on the above features, when the type's BitWidth meets the
requirements, all `SINT_TO_FP` are legal, all `UINT_TO_FP` are expand
and lowered to libcall when appropriate.
The only special case is, LoongArch64 with `+f,-d` features. At this
point, custom processing is required for `[SU]INT_TO_FP`. Of course, we
can also ignore it and use libcall directly.

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

CMPSXADD will modify memory, so we can't use `IntrArgMemOnly` here.
Found it during review D137250.

Fix a brown paper bag error made by me in D129418.  I didn't set
ASAN_INTERCEPT_VFORK correctly for loongarch64, but created an all-zero
object for __interception::real_vfork.  This caused anything calling
vfork() to die instantly.

Fix this issue by setting ASAN_INTERCEPT_VFORK and remove the bad
all-zero definition.  Other ports have an all-zero common definition but
we don't need it at least for now.

And, enable ASAN vfork test for loongarch64 to prevent regression in the
future.

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

Instrumentation passes now use the proper shadow offset. There will be many
asan test failures without this patch. For example:

```
$ ./lib/asan/tests/LOONGARCH64LinuxConfig/Asan-loongarch64-calls-Test
AddressSanitizer:DEADLYSIGNAL
=================================================================
==651209==ERROR: AddressSanitizer: SEGV on unknown address 0x1ffffe2dfa9b (pc 0x5555585e151c bp 0x7ffffb9ec070 sp 0x7ffffb9ebfd0 T0)
==651209==The signal is caused by a UNKNOWN memory access.
```

Before the patch:

```
$ make check-asan
Testing Time: 36.13s
  Unsupported      : 205
  Passed           :  83
  Expectedly Failed:   1
  Failed           : 239
```

After the patch:
```
$ make check-asan
Testing Time: 58.98s
  Unsupported      : 205
  Passed           : 421
  Expectedly Failed:   1
  Failed           :  89
```

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

This enables odr indicators on all platforms and private aliases on non-Windows.
Note that GCC also uses private aliases: this fixes bogus
`The following global variable is not properly aligned.` errors for interposed global variables

Fix https://github.com/google/sanitizers/issues/398
Fix https://github.com/google/sanitizers/issues/1017
Fix https://github.com/llvm/llvm-project/issues/36893 (we can restore D46665)

Global variables of non-hasExactDefinition() linkages (i.e.
linkonce/linkonce_odr/weak/weak_odr/common/external_weak) are not instrumented.
If an instrumented variable gets interposed to an uninstrumented variable due to
symbol interposition (e.g. in issue 36893, _ZTS1A in foo.so is resolved to _ZTS1A in
the executable), there may be a bogus error.

With private aliases, the register code will not resolve to a definition in
another module, and thus prevent the issue.

Cons: minor size increase. This is mainly due to extra `__odr_asan_gen_*` symbols.
(ELF) In addition, in relocatable files private aliases replace some relocations
referencing global symbols with .L symbols and may introduce some STT_SECTION symbols.

For lld, with -g0, the size increase is 0.07~0.09% for many configurations I
have tested: -O0, -O1, -O2, -O3, -O2 -ffunction-sections -fdata-sections
-Wl,--gc-sections. With -g1 or above, the size increase ratio will be even smaller.

This patch obsoletes D92078.

Don't migrate Windows for now: the static data member of a specialization
`std::num_put<char>::id` is a weak symbol, as well as its ODR indicator.
Unfortunately, link.exe (and lld without -lldmingw) generally doesn't support
duplicate weak definitions (weak symbols in different TUs likely pick different
defined external symbols and conflict).

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

This document aims to give insights at the representation of procdure
pointers in FIR.

Reviewed By: PeteSteinfeld, jeanPerier, kiranchandramohan

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

It's not necessary to redo the source file preprocessing for reproducing linker
crashes because we must have successfully created the object file by this point.
Skip this step, and also don't report the preprocessed source file or create
the clang invocation shell script. The latter is no longer sensible without the
preprocessed source, or helpful given the linker reproducer will have it's own
shell script.

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

Materializing scalable vectors with boolean values is not implemented
yet. Skip those cases for now and leave a TODO.

Per discussions in D128745, remove ClangABICompat checks for implementations
of DR692/DR1395/DR1432. This is a potentially breaking changes, so the release
note is updated accordingly.

Reviewed By: aaron.ballman

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

Fixes null dereference in emitFunctionBodyStart for 64-bit

The empty set will be default constructed if this wasn't
in the map already.

The call_intrinsic op allows us to call LLVM intrinsics from the LLVMDialect without implementing a new op every time.

Reviewed By: lattner, rriddle

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

A bug in the file read logic has also been fixed along the way. Parts
of the ungetc tests will fail without that bug fixed.

Reviewed By: michaelrj

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

The instruction icmp ule <4 x i32> %0, zeroinitializer will usually be
simplified to icmp eq <4 x i32> %0, zeroinitializer. It is not
guaranteed though, and the code for lowering vector compares could pick
the wrong form of the instruction if this happened. I've tried to make
the code more explicit about the supported conditions.

This fixes NEON being unable to select VCMPZ with HS conditions, and
fixes some incorrect MVE patterns.

Fixes #58514.

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

This target (as well as 32-bit ARM Android) have sizeof(long double)
equal to sizeof(double).

Reviewed By: ldionne, #libc

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

Mark tests XFAIL that use APIs that are unsupported on old versions of
Android:
 - aligned_alloc isn't available until API 28.
 - timespec_get isn't available until API 29.

Reviewed By: ldionne, #libc

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

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

This change will switch SizeClassAllocator32 to SizeClassAllocator64 on ARM. This might potentially affect ARM platforms with 39-bit address space. This addresses [[ https://github.com/google/sanitizers/issues/703  | issues/703  ]], but unlike [[ https://reviews.llvm.org/D60243 | D60243 ]] it defaults to 64 bit allocator.

Reviewed By: vitalybuka, MaskRay

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

These were accidentally set to generating in
243da90e

Reviewed By: #libc, philnik

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

Remove the eliminateBlockingAwaitOps option in AsyncToAsyncRuntime pass

Today the AsyncToAsyncRuntime pass does two things: one is converting normal funcs with async ops to coroutine cfg; the other is lowering high level async operations to async.coro and async.runtime operations. This patch removes the converting step from AsyncToAsyncRuntime pass.

In the next step we will create a new asyncfication pass for converting normal funcs to the newly added async.func operation.

Reviewed By: ezhulenev

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

This change modifies the implementation of the format() function
so that vendor forks committed to building with compilers that
support __attribute__((format)) on non-variadic functions can
check the format() function with it.

rdar://84571523

RVVBitsPerBlock is 64. If VLen==32, VLen/RVVBitsPerBlock is 0.

Reviewed By: reames

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

Fix setting affinity type and topology method when affinity is disabled
and fix places that were not taking into account that affinity can be
explicitly disabled by putting proper KMP_AFFINITY_CAPABLE() check.

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