This method was simply a wrapper around readOrError. All users within
the llvm-exegesis code base should have been processing an actual error
rather than using the wrapper. This patch removes the wrapper and
rewrites the users (just 1) to use the readOrError method.

This patch removes redundant SPF support
(https://github.com/llvm/llvm-project/commit/5350e1b5096aa4707aa525baf7398d93b4a4f1a5)
from `computeKnownBitsFromOperator` as we always canonicalize a SPF into
an intrinsic call.

Compile-time improvement:
http://llvm-compile-time-tracker.com/compare.php?from=3dc0638cfc19e140daff7bf1281648daca8212fa&to=8771ef0749fb2ba4304dc68d418c88ec5769346f&stat=instructions:u

|stage1-O3|stage1-ReleaseThinLTO|stage1-ReleaseLTO-g|stage1-O0-g|stage2-O3|stage2-O0-g|stage2-clang|
|--|--|--|--|--|--|--|
-0.01%|-0.01%|+0.01%|+0.00%|+0.01%|+0.04%|-0.01%|

Fixed a bug where IntMatrix determinant() had a bug where it would try to assign to a null
pointer.
Added a test case that triggers this bug to avoid regressions.

The revision moves pack/unpack related patterns to
PackAndUnpackPatterns.cpp. This follows the convention like other tensor
ops.

It also renames `populateSimplifyTensorPack` to
`populateSimplifyPackAndUnpackPatterns` and adds a TODO item for
tensor.unpack op.

Add the required CMAKE_BUILD_TYPE to the cmake configuration line.

We drop the comment about enabling tests, since it is already implied
and doesn't add any additional context.

This patch makes minor adjustments to the llvm-exegesis docs for
clarity. Particularly, an update is made to the list of snippet
annotations to list the correct number of annotations that was not
updated when the docs were originally updated for the snippet address
annotation. In addition, this patch changes a decimal value for the
snippet memory annotation example for an explicit hex value to emphasize
that the LLVM-EXEGESIS-MEM-DEF annotation takes a hex value for the
memory value.

Builtins.def says that bfloat should be represented by the 'y'
character, not the 'b' character. The 'b' character is specified to
represent boolean. The implementation currently uses 'b' correctly for
boolean and incorrectly re-uses 'b' for bfloat.

This was not caught since no builtins are emitted in
build/tools/clang/include/clang/Basic/riscv_sifive_vector_builtins.inc.
Don't know that we can test this without creating builtins that expose
this issue, although I'm not sure we really want to do that.

The status table incorrectly marks P0521R0 as nothing to do. This is not
correct the function should be deprecated.
During our latest monthly meeting we argreed to remove the
_LIBCPP_ENABLE_CXXyy_REMOVED_FEATURES macros, therefore the new macro is
not
added to that global list.

Implements
- P0521R0 Proposed Resolution for CA 14 (shared_ptr use_count/unique)

Implements parts of
- P0619R4 Reviewing Deprecated Facilities of C++17 for C++20

---------

Co-authored-by: Nikolas Klauser <nikolasklauser@berlin.de>

The patch adds the instructions in Zicfiss extension. Zicfiss extension
is to support shadow stack for control flow integrity. This patch is
based on version [0.3.1].

[0.3.1]: https://github.com/riscv/riscv-cfi/releases/tag/v0.3.1

The original PR had a typo which was causing a bug.

Co-authored-by: Balazs Benics <benicsbalazs@gmail.com>

These instructions are legal in the presence of Zbkb extension.

Add tests for llvm.abs.
This is a preparation for
https://github.com/llvm/llvm-project/pull/73189

Test plan: ninja check-all

Closes #52975.

This patch switches out the `and` keyword for && in preprocessor
directives recently added to fix some buildbot failures to be consistent
with the rest of the code base.

…r instruction.

Before
https://github.com/llvm/llvm-project/commit/77a609b55636dc540090ef9105c60a99cfdbd1dd,
we always skip in-tree uses of the vectorized scalars in
`buildExternalUses()`,
that commit handles the case that if the in-tree use is scalar operand
in vectorized instruction,
we need to generate extract for these in-tree uses.

in-tree uses remain as scalar in vectorized instructions can be 3 cases:
- The pointer operand of vectorized LoadInst uses an in-tree scalar
- The pointer operand of vectorized StoreInst uses an in-tree scalar
- The scalar argument of vector form intrinsic uses an in-tree scalar

Generating extract for in-tree uses for vectorized instructions are
implemented in `BoUpSLP::vectorizeTree()`:
-
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp#L11497-L11506
-
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp#L11542-L11551
-
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp#L11657-L11667

However,
https://github.com/llvm/llvm-project/commit/77a609b55636dc540090ef9105c60a99cfdbd1dd
not only generates extract for vectorized instructions,
but also generates extract for original scalar instructions.
There is no need to generate extract for origin scalar instrutions,
as these scalar instructions will be replaced by vector instructions and
get erased later.

This patch marks there is no exact user for in-tree scalars that 
remain as scalar in vectorized instructions when building external uses,
In this case all uses of this scalar will be automatically replaced by extractelement.
and remove
-
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp#L11497-L11506
-
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp#L11542-L11551
-
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp#L11657-L11667
extracts.

a15532d7 landed a patch that added
support for detecting more AMD znver2 CPUs and cleaned up some of the
surrounding code, including the znver3 detection. Since one model group
is 00h-0fh, I adjusted the check to include checking if the value is
greater than zero. Since the value is unsigned, this is always true and
gcc warns on it. This patch removes the comparison with zero to get rid
of the compiler warning.

Previous patches moved the save/restore system call register functions
behind a preprocessor check, but neglected to move the constant
expression array used by the functions behind the preprocessor check.
This patch gates the array behind the preprocessor check to fix build
failures caused by -Werror,unused-const-variable on the clang--ppc64-aix
buildbot.

Relanding this patch broke some builds (including Windows) due to
certain functions not being guarded by appropriate preprocessor
directives, particularly the loadImmediateSegmentRegister function not
having most of its functionality only enabled on Linux. The previous
relanding addressed issues with headers not being available on
non-x86_64 linux, but neglected to fix issues with the header not being
included, but the function still trying to use it on certain platforms,
such as x86-64 windows.

This reverts commit 8b485070.

This relands commit 7c383481.

This caused build failures on non-x86-64 builders as there was no
preprocessor logic around the newly included headers. This has been
fixed in the relanded patch.

Summary:
In the future, we may have more checks for different kinds of inputs,
e.g. SPIR-V. This patch simply reworks the handling to be more generic
and do the magic detection up-front. The checks inside the routines are
now asserts so we don't spend time checking this stuff over and over
again.

This patch also tweaked the bitcode check. I used a different function
to get the Lazy-IR module now, as it returns the raw expected value
rather than the SM diganostic.

No functionality change intended.

Most asan tests `FAIL` on FreeBSD 14.0/amd64 with
```
==17651==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
```
With `ASAN_OPTIONS=verbosity=2` one sees:
```
==4880==info->dlpi_name = [vdso]	info->dlpi_addr = 0xffffe780
==4880==info->dlpi_name = lib/clang/18/lib/freebsd/libclang_rt.asan-i386.so	info->dlpi_addr = 0x2808a000
```
Ignoring the vDSO as on Linux fixes this.

Tested on `amd64-pc-freebsd14.0`.

Fixes llvm/llvm-project#76314

This adds the ROCm device libs defines for both target architectures so
that we an compile libc on such GPUs.

Summary:
This was actually set, I just forget where it was.

Summary:
The AMDGPU architecture does not use a fixed frequency for all of its
architectures. However, the newer GPUs tend to have one that's
consistent between them (Except for Vega10). This was set up but not
actually used, so the implementation was just defaulting to whatever
value the global was being set to. Fix.

And disable offset folding altogether since we cannot always gain the
precise offset there to see if that fits into a certain size of
displacement.

The MximmSExt8/16/32 should be "any immediate that can be represented by
8/16/32-bit signed integer", hence it shouldn't express an explicit
type. Rename those into Mxi8/16/32immSExt8/16/32.

NFC.

Alive2: https://alive2.llvm.org/ce/z/Qdsqk6

The commit https://github.com/llvm/llvm-project/commit/f1eda235142ed071e219bd231310e44cda08f932
didn't handle other cases that commute operands.

 [builtins] Fix CPU feature detection for FreeBSD on AArch64

This is a follow-up to #75635 which broke the build for FreeBSD on
AArch64:

```
compiler-rt/lib/builtins/cpu_model/aarch64/lse_atomics/freebsd.inc:3:16: error: call to undeclared function 'elf_aux_info'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    3 |   int result = elf_aux_info(AT_HWCAP, &hwcap, sizeof hwcap);
      |                ^
```

Using `elf_aux_info()` requires including `<sys/auxv.h>` first. To
prevent redeclaration issues with `hwcap.inc` attempting to define
`HWCAP_xxx` macros before `<sys/auxv.h>` does so, include `<sys/auxv.h>`
before any of the `.inc` files on FreeBSD.

Support for FreeBSD 11.x was dropped so garbage collect a few FreeBSD
9.x workarounds and make 12.x the oldest supported releases.