This patch adds the assembly/disassembly for the following instructions:

cntp : Set scalar to count from predicate-as-counter

The reference can be found here:
https://developer.arm.com/documentation/ddi0602/2022-09

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

This patch adds the assembly/disassembly for the following instructions:
  BMOPA: Bitwise exclusive NOR population count outer product and accumulate.
  BMOPS: Bitwise exclusive NOR population count outer product and subtract.

  SMOPA (2-way): Signed integer sum of outer products and accumulate.
  SMOPS (2-way): Signed integer sum of outer products and subtract.

  UMOPA (2-way): Unsigned integer sum of outer products and accumulate.
  UMOPS (2-way): Signed integer sum of outer products and accumulate.
The reference can be found here:

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

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

Fix the following build failures:
```
In file included from /home/loongson/llvm-work/llvm-project/compiler-rt/lib/sanitizer_common/sanit>
llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_syscall_linux_loongarch64.inc:27:23: error>
  register u64 a7 asm("a7") = nr;
                      ^
llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_syscall_linux_loongarch64.inc:28:23: error>
  register u64 a0 asm("a0");                      ^
```

The non-prefix `$` syntax in inline assembly is not supported in clang
yet (it is supported by gcc), add prefix `$` to solve the problem.

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

- Add get_bits_for_arch for loongarch64 detection, fix the following error,
```
$ make check-asan
-- sanitizer_common tests on "Linux" will run against "asan"
CMake Error at test/asan/CMakeLists.txt:22 (message):
  Unknown target architecture: loongarch64
Call Stack (most recent call first):
  test/asan/CMakeLists.txt:49 (get_bits_for_arch)
```

- Do not use __builtin_longjmp, fix the following error,
```
llvm-project/compiler-rt/lib/asan/tests/asan_test.cpp:635:3: error: __builtin_longjmp is not supported for the current target
  __builtin_longjmp((void**)buf, 1);
```

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

There are two failures in the current builtins,
Failed Tests (2):
  Builtins-loongarch64-linux :: clear_cache_test.c
  Builtins-loongarch64-linux :: enable_execute_stack_test.c

It is caused by __clear_cache not being implemented and triggering `abort`.

"__clear_cache" is implemented in the same way as "clear_cache" in gcc (
in gcc/config/loongarch/loongarch.md)

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

Initial builtins for LoongArch.
Add loongarch64 to ALL_CRT_SUPPORTED_ARCH list.
Support fe_getround and fe_raise_inexact in builtins.

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

[X86] combineConcatVectorOps - fold 512-bit concat(GF2P8AFFINEQB(x,y,c),GF2P8AFFINEQB(z,w,c)) -> GF2P8AFFINEQB(concat(x,z),concat(y,w),c)

Now that D137036 has landed, we just need AVX512F support to generate 512-bit GF2P8AFFINEQB ops

Originaly the loop did almost nothing as the calculated location was
overwritten on the next iteration.

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

It's incorrect to reuse live registers left from the first instruction in a clause after the clause as they don't contain in-clause defs.

Reviewed By: arsenm

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

This patch adds the assembly/disassembly for the following instructions:

st1*   : Contiguous store of bytes to multiple consecutive vectors -
 (scalar + scalar) and (scalar + immediate)
stnt1* : Contiguous store non-temporal of bytes to multiple consecutive
 vectors - (scalar + scalar) and (scalar + immediate)

The reference can be found here:
https://developer.arm.com/documentation/ddi0602/2022-09

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

This patch adds the assembly/disassembly for the following instructions:

ld1*   : Contiguous load of bytes to multiple consecutive vectors -
         (scalar + scalar) and (scalar + immediate)
ldnt1* : Contiguous load non-temporal of bytes to multiple consecutive
         vectors - (scalar + scalar) and (scalar + immediate)

The reference can be found here:
https://developer.arm.com/documentation/ddi0602/2022-09

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

As pointed out in the review https://reviews.llvm.org/D135523#C3696894NL515

Define LoongArch architecture subtypes, add the LoongArch ArchSpec bits,
and inspect the ELF header to detect the right subtype based on ELF class.

Here is a simple test:

```
[loongson@linux ~]$ cat hello.c

int main()
{
	printf("Hello, World!\n");
	return 0;
}
[loongson@linux ~]$ clang hello.c -g -o hello
```

Without this patch:

```
[loongson@linux ~]$ llvm-project/llvm/build/bin/lldb hello
(lldb) target create "hello"
error: '/home/loongson/hello' doesn't contain any 'host' platform architectures: unknown
```

With this patch:

```
[loongson@linux ~]$ llvm-project/llvm/build/bin/lldb hello
(lldb) target create "hello"
Current executable set to '/home/loongson/hello' (loongarch64).
(lldb) run
Process 735167 launched: '/home/loongson/hello' (loongarch64)
Hello, World!
Process 735167 exited with status = 0 (0x00000000)
(lldb) quit
[loongson@linux ~]$ llvm-project/llvm/build/bin/llvm-lit llvm-project/lldb/test/Shell/ObjectFile/ELF/loongarch-arch.yaml
llvm-lit: /home/loongson/llvm-project/llvm/utils/lit/lit/llvm/config.py:456: note: using clang: /home/loongson/llvm-project/llvm/build/bin/clang
-- Testing: 1 tests, 1 workers --
PASS: lldb-shell :: ObjectFile/ELF/loongarch-arch.yaml (1 of 1)

Testing Time: 0.09s
  Passed: 1
```

Reviewed By: SixWeining, xen0n, DavidSpickett

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

We currently only take operand bundle effects into account when
querying the function-level memory attributes. However, I believe
that we also need to do the same for parameter attributes. For
example, a call with deopt bundle to a function with readnone
parameter attribute cannot treat that parameter as readnone,
because the deopt bundle may read it.

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

This was fixed in bf789b19

FRINT uses dynamic rounding mode instead of static rounding mode. The patch
rename VFCVT_X_F_VL to VFCVT_RM_X_F_VL for static rounding mode uses and added
new ISDNode VFCVT_X_F_VL directly selected to PseudoVFCVT_X_F_V.

Reviewed By: craig.topper

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

We were only testing targets with legal 16-bit operations.

Automatically cleanup operations if we know the atomic has higher
alignment.

Add a `pyproject.toml` file that provides build system information
for PEP 517-compliant builders.  While all the commonly used builders
provide fallback to running `setup.py` for backwards compatibility, this
ensures the best forward compatibility.  It also provides a reliable way
of specifying the minimum required setuptools version.  Effectively, it
will make it possible to remove `setup.py` in favor of purely
declarative configuration in the future, or even switch to a different
build system.

Update `setup.py` to explicitly add the current directory to `sys.path`
for importing `lit`.  This is necessary, as the modern setuptools
backend does not guarantee that the current directory is present there.

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

Set proper offset to the second element of the index pair, so that
we do not have same index values for more than one local expression.

Reviewed By: springerm

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

* Windows doesn't support setting these breakpoints by basename
* On Linux std::function arguments aren't formatted as such

This diff annotates more methods of the class Instruction with
LLVM_READONLY (similarly to isAssociative/isCommutative).

Test plan: ninja check-all

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

Reviewed By: ABataev

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

This reverts commit 37acf9bd.  It broke
a buildbot.

AAPointerInfo now maintains a list of all Access objects that it owns, along
with the following maps:

- OffsetBins: OffsetAndSize -> { Access }
- InstTupleMap: RemoteI x LocalI -> Access

A RemoteI is any instruction that accesses memory. RemoteI is different from
LocalI if and only if LocalI is a call; then RemoteI is some instruction in the
callgraph starting from LocalI.

Motivation: When AAPointerInfo recomputes the offset for an instruction, it sets
the value to Unknown if the new offset is not the same as the old offset. The
instruction must now be moved from its current bin to the bin corresponding to
the new offset. This happens for example, when:

- A PHINode has operands that result in different offsets.
- The same remote inst is reachable from the same local inst via different paths
  in the callgraph:

```
               A (local inst)
               |
               B
              / \
             C1  C2
              \ /
               D (remote inst)

```
This fixes a bug where a store is incorrectly eliminated in a lit test.

Reviewed By: jdoerfert

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

Most tools accept .ll or .bc inputs interchangably, but some don't.
Default to writing temporary files that match the input. This
will also aid reducing deserialization bugs.

Previously, this unconditionally emitted text IR. I ran
into a bug that manifested in broken disassembly, so the
desired output was the bitcode format. If the input format
was binary bitcode, the requested output file ends in .bc,
or an explicit -output-bitcode option was used, emit bitcode.

Replace the use of the deprecated `llvm-config` tool with LLVM's CMake
files for detecting LLVM in standalone builds.

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

This was also trying to write the bitcode to the failed file
on failure, which asserts. Also, consistently use
ToolOutputFile, instead of one path manually removing
the temp file.

This wasn't used by every atomicrmw expansion.

Unlike just about every target, I don't
see an obvious null dereference this fixes.

There should no need for null checks in the AsmPrinter