This reverts commit 19b44c2b.

The reason for the revert is discussed at:
https://discourse.llvm.org/t/rfc-improving-lits-debug-output/72839/52

This reverts commit efec733b.

The reason for the revert is discussed at:
https://discourse.llvm.org/t/rfc-improving-lits-debug-output/72839/52

This reverts commit e91e3cf0 because
AMD BB is not happy with it.

This is needed because `cpp::in_place_t` is also used by `cpp::expected`
https://en.cppreference.com/w/cpp/utility/in_place

This patch replaces any_cast with llvm::any_cast. This in turn allows us
to gracefully switch to std::any in future by forwarding llvm::Any and
llvm::any_cast to:

  using Any = std::any;

  template <class T> T *any_cast(Any *Value) {
    return std::any_cast<T>(Value);
  }

respectively.

Without this patch, it's ambiguous whether any_cast refers to
std::any_cast or llvm::any_cast.

As an added bonus, this patch makes it easier to mechanically replace
llvm::any_cast with std::any_cast without affecting other occurrences of
any_cast (e.g. in libcxx).

Add a [-b|--bootstrap] flag to change cxx-test-depends to
runtimes-test-depends when testing a build of libcxx from bootstrapping.

Signed-off-by: Will Hawkins <hawkinsw@obs.cr>

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

Recently, 7f26c27e turned on SLP by default for RISC-V, and although
there are quite a few tests for SLP under the X86/ target, it is unclear
whether the same constructs would be vectorized on RISC-V. This patch
takes a step in the direction of remedying this, by noticing that ctpop
is often vectorized on RISC-V, and adding four tests for different
integer widths.

This adds a lowering similar to the general shape_cast lowering, but
instead moves elements a (scalable) subvector at a time via
vector.scalable.extract/insert. It is restricted to the case where both
the source and result vector types have a single trailing scalable
dimension (due to limitations of the insert/extract ops).

The current lowerings are now disabled for scalable vectors, as they
produce incorrect results at runtime (due to assuming a fixed number
of elements).

Examples of casts that now work:

  // Flattening:
  %v = vector.shape_cast %arg0 : vector<4x[8]xi8> to vector<[32]xi8>

  // Un-flattening:
  %v = vector.shape_cast %arg0 : vector<[8]xi32> to vector<2x1x[4]xi32>

Reviewed By: awarzynski, nicolasvasilache

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

After many years of using the really old std::pair ABI which did not yet
have a trivial copy constructor, FreeBSD 14 and later will finally get
rid of it. Only use the old ABI for FreeBSD 13 and earlier.

Note: on the FreeBSD side, we will bump our libc++.so version for this,
and keep an old compatibility library in a separate package.

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

[NFC][mlir][bufferization] Add paragraph about runtime and space cost to bufferization.dealloc op documentation (#65612)

The icmp is being folded in phi only if they belong in the same BB.
This patch extends the same beyond the BB.
Have seen scenarios where this seems to be beneficial.

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

This commit allows to omit insertion of the memref.dealloc operation
when linalg.structured.bufferize_to_allocation is run and makes this the
default behavior. This is desirable when the
buffer-deallocation-pipeline is run after bufferization to handle buffer
deallocation.

Prior to this patch, libcxx/test/libcxx/strings/basic.string/string.capacity/max_size.pass.cpp
would fail for RISC-V. The __riscv macro is defined for both RV32 and RV64.

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

This removes some std::function boilerplate from my profile of the
most frequently called functions in llc. The geomean speed up of 0.01%
just barely shows up on https://llvm-compile-time-tracker.com/

Fix signed zeros for acosf, acoshf, and atanf in FE_DOWNWARD mode.

Reviewed By: sivachandra

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

This implements the second step of
https://discourse.llvm.org/t/rfc-customizable-namespace-to-allow-testing-the-libc-when-the-system-libc-is-also-llvms-libc/73079

Namely "Add a guard in `src/__support/common.h`"

On PowerPC the number of TOC entries must be kept low for large
applications. In order to reduce the number of constant global arrays
we can pool them into one structure and then access them as the base
address of that structure plus some offset. The constant global arrays
may be arrays of `i8` which are constant strings but they may also be
arrays of `i32, i64, etc...`.

Reviewed By: lei, amyk

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

Failure introduced in 8cd4ecfa

The opaque pointers are already "canonicalized". So remove the
redundant/obsolete code.

This patch allows to supply an optional memory space of the promoted
buffer.

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

…metic

The intention of this test file long term is to test all valid (LMUL,
SEW) pairs for each SchedWrite class. For this reason, we do not test
every single instruction under every (LMUL, SEW) pair, since multiple
instructions may use the same SchedWrite. For example, vadd.vv and
vsub.vv both use the WriteVIALUV class.

I didn't end up getting all (LMUL, SEW) pair for each SchedWrite class
though. For example, vadd.vv and vadd.vx use WriteVIALUV and WriteVIALUX
respectivley, but I treated all Vector Single-Width Integer Add and
Subtract instructions as having the same behavior. I plan on improving
the coverage as time goes on and figured this would be a good start. If
there is any class of vector integer arithmetic instructions you'd like
to see full coverage for in this patch, please let me know.

umin.i1 -> and : https://alive2.llvm.org/ce/z/6FNH6k
smin.i1 -> or : https://alive2.llvm.org/ce/z/h96S6o
umax.i1 -> or : https://alive2.llvm.org/ce/z/XHdeVk
smax.i1 -> and : https://alive2.llvm.org/ce/z/fkxKJx
umin.v4i1 -> and : https://alive2.llvm.org/ce/z/yV4VgP
smin.v4i1 -> or : https://alive2.llvm.org/ce/z/e9TF68
umax.v4i1 -> or : https://alive2.llvm.org/ce/z/tfNyfK
smax.v4i1 -> and : https://alive2.llvm.org/ce/z/0__Af2

Reviewed By: goldstein.w.n, bryanpkc

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

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

The DWARFLinker library has code to identify ObjC selector names, which is used
by the debug linker to generate accelerator table entries. In the future, we
would like the DWARF verifier to also have access to such code, so that it can
identify these names when verifying accelerator tables (e.g. debug_names).

This patch follows the same intent of D155723, where we also moved code
generating simplified template names.

Since this is moving code around and changing the log, we also replace raw
pointer manipulation with the more expressive
StringRef::{drop_front,take_front,...} methods.

We also change a test so that it verifies its output, and that requires having
dsymutil not write to stdout.

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

Revert "[X86][RFC] Add new option `-m[no-]evex512` to disable ZMM and 64-bit mask instructions for AVX512 features"

This reverts commit 7dd48cc2.

Causing buildbot failure.

Some people may not have access to `gh` or may prefer to use `git` and
the GitHub web interface to make a PR. This patch adds an example of
making a PR using this approach.

The test was looking only for the bitcode writer pass; it should check
the full pipeline to make sure the choice is as intended.

[X86][RFC] Add new option `-m[no-]evex512` to disable ZMM and 64-bit mask instructions for AVX512 features

This is an alternative of D157485 and a pre-feature to support AVX10.

AVX10 Architecture Specification: https://cdrdv2.intel.com/v1/dl/getContent/784267
AVX10 Technical Paper: https://cdrdv2.intel.com/v1/dl/getContent/784343
RFC: https://discourse.llvm.org/t/rfc-design-for-avx10-feature-support/72661

Based on the feedbacks from LLVM and GCC community, we have agreed to
start from supporting `-m[no-]evex512` on existing AVX512 features.
The option `-mno-evex512` can be used with `-mavx512xxx` to build
binaries that can run on both legacy AVX512 targets and AVX10-256.

There're still arguments about what's the expected behavior when this
option as well as `-mavx512xxx` used together with `-mavx10.1-256`. We
decided to defer the support of `-mavx10.1` after we made consensus.
Or furthermore, we start from supporting AVX10.2 and not providing any
AVX10.1 options.

Reviewed By: RKSimon, skan

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