efd64c2f added these.

[hwasan] provide a runtime flag for printing remaining threads in error report as an extra information

This patch adds a runtime flag `print_live_threads_info`, which defaults to true, controls whether or not prints remaining threads in error report as an extra information.
We(ByteDance) are in the process of enabling hwasan for our server-side applications on AArch64/Linux, these server-side applications have thousands of threads, so it is nice to have this option.

Reviewed By: fmayer

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

Linking LLVMCore failed when building D148536 with shared libs enabled:
https://lab.llvm.org/buildbot/#/builders/121/builds/29766

Make isPointerOffset a Value method and rename it to getPointerOffsetFrom.

Reviewed By: jmorse

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

Don't link libc++abi separately in addition to the main -lc++; in
mingw build configs, libc++abi is always bundled into libc++
(via LIBCXX_ENABLE_STATIC_ABI_LIBRARY).

In the case of a shared linked libc++, linking a separate static
libc++abi leads to linker errors.

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

With current versions of mingw-w64 headers, code following
assert(false) isn't considered unreachable - thus add a dummy
"return nullptr;", to avoid warnings (treated as errors) for a
missing return statement.

The root cause does get fixed further upstream in mingw-w64 in
https://github.com/mingw-w64/mingw-w64/commit/1690994f515910a31b9fb7c7bd3a52d4ba987abe
though.

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

This matches the corresponding change to libcxx headers in
dfa88927.

This avoids needing to define _LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS
when building libcxxabi tests, for two reasons:
- It defaults to normal linkage (as opposed to dllimport), fixing
  linking of a static library version of libcxx/libcxxabi
- It avoids issues with using dllimport declarations on symbols when
  including cxxabi implementations into the testcase itself

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

Add cost for extending to illegal scalable vector types.
Add testing file for the extend operations.

Reviewed By: sdesmalen

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

Otherwise one gets the following warning with GCC:
warning: ignoring ‘#pragma clang diagnostic’ [-Wunknown-pragmas]

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

More specifically make it more talkative when it's looking at the users of
an alloca to promote it to a vector.

A common failure point of the pass is unknown or weird users of the alloca.
While debugging issues related to this pass one of the first thing I usually
did was to add logs to see how the users were being handled.
Having such logs in directly seems to be a nice addition.

Reviewed By: arsenm, rampitec

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

distutils is deprecated and shutil.which is the suggested
replacement for this function.

https://peps.python.org/pep-0632/#migration-advice
https://docs.python.org/3/library/shutil.html#shutil.which

which was added in 3.3 (https://docs.python.org/3/library/shutil.html#shutil.which)
and LLVM requires at least 3.6 (https://llvm.org/docs/GettingStarted.html#software).

Reviewed By: delcypher, vitalybuka

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

This reverts commit fca3e8e0.

Buildbot: https://lab.llvm.org/buildbot/#/builders/121/builds/29766

This reverts commit 107b307b due
to build errors in a parent commit fca3e8e0

This reverts parts of D123693. The functionality of allowing unsupported
intrinsics to select has been superseded by D139000 "Remove function
with incompatible features".

Retain assembler/disassembler support for v_illegal on GFX10+ only,
where it is documented.

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

The cmake command contained a duplicate CMAKE_BUILD_TYPE option in the
section "Compiling the LLVM Suite Source Code".

These sequence of calls don't really make sense for head_tail and loop_and_tail.

If we're concatenating several smaller loads separated by a stride, we
can try and increase the element size and perform a strided load.
For example:

```
concat_vectors (load v4i8, p+0), (load v4i8, p+n), (load v4i8, p+n*2), (load v4i8, p+n*3)
=>
vlse32 p, stride=n, VL=4
```

This pattern can be produced by the SLP vectorizer.

A special case is when the stride is exactly equal to the width of the
vector, in which case it can be converted into a single consecutive
vector load. For example:

```
concat_vectors (load v4i8, p), (load v4i8, p+4), (load v4i8, p+8), (load v4i8, p+12)
=>
vle8 p, VL=16
```

Reviewed By: craig.topper

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

These patterns of concat_vector nodes of loads can be combined into
widened vector loads or a strided vector loads.

Co-authored-by: Philip Reames <preames@rivosinc.com>

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

This reverts commit efc8b52c
which reverts D146987.

See https://reviews.llvm.org/D146987 for issues.

`shortenAssignment` inserts dbg.assigns with fragments describing the dead part
of a shortened store after each dbg.assign linked to the store.

Without this patch it doesn't take into account that the dead part of a
shortened store may be outside the bounds of a variable of a linked
dbg.assign. It also doesn't correctly account for a non-zero offset in the
address modifying `DIExpression` of the dbg.assign (which is possible for
fragments now even though whole variables currently cannot have a non-zero
offset in their alloca).

Fix this by moving the dead slice into variable-space and performing an
intersect of that adjusted slice with the existing fragment.

This fixes a verifier error reported when building fuchsia with assignment
tracking enabled:
https://ci.chromium.org/ui/p/fuchsia/builders/ci/
        clang_toolchain.ci.core.x64-release/b8784000953022145169/overview

Reviewed By: jmorse

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

This reverts commit 6f7e5c0f.

Seems to expose a miscompile in rust, possibly exposing a bug in LLVM
somewhere. Investigation thread over at:
https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm/topic/LLVM.20D146629.20breakage

RVV stands for "RISC-V V Extension", which adds 32 vector registers, and seven unprivileged CSRs (vstart, vxsat, vxrm, vcsr, vtype, vl, vlenb) to a base scalar RISC-V ISA.

The base vector extension is intended to provide general support for data-parallel execution within the 32-bit instruction encoding space, with later vector extensions supporting richer functionality for certain domains.

This patch adds the definitions of RVV registers in `RegisterInfos_riscv64.h`, whose purpose is to provide support (such as reading, writing, and calculating the offsets) for future register-related functions.

Reviewed By: kito-cheng

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

This will be used for writing test cases.

~~

Huawei RRI, OS Lab

Reviewed By: courbet

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

The array component indices in the "path" of a fir.slice are zero based
because FIR does not know about the component lower bounds.
When lowering hlfir.designate to FIR for `array%x(i, j)`, convert `i` and
`j` to zero based indices before generating the fir.slice.

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

There are some patterns in td files without MVT/class set
for some operands in target pattern that are from the source
pattern. This prevents GlobalISelEmitter from adding them as
a valid rule, because the target child operand is an
unsupported kind operand. For now, for a leaf child, only
IntInit and DefInit are handled in GlobalISelEmitter.

This issue can be workaround by adding MVT/class to the
patterns in the td files, like the workarounds for patterns
anyext and setcc in PPCInstrInfo.td in D140878.

To avoid adding the same workarounds for other patterns in
td files, this patch tries to handle the UnsetInit case in
GlobalISelEmitter.

Adding the new handling allows us to remove the workarounds
in the td files and also generates many selection rules for
PPC target.

Reviewed By: arsenm

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

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

As noted in https://reviews.llvm.org/D148315, the ordering logic for
OrderedExtensionMap currently puts s* before z* extensions, but per the
ISA manual the correct order should be z* and then s* (with the
exception of zxm*, which are ordered after s*).

This patch fixes the ordering and adds a TODO for zxm*. The changes are
visible in the test case added in
a35e67fc which also demonstrates an
issue with the ordering of single letter extensions (which isn't
addressed in this patch).

This ordering matches the one used by GCC/binutils as well.

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

2a5661c8 added a new external link with
the link text "0.2 draft specification". Surprisingly, as multiple links
have this same text but different targets this causes a warning, which
causes a failure on the llvm-sphinx-docs builder (which treats warnings
as errors). As suggested in
<https://github.com/sphinx-doc/sphinx/issues/3921>, this commit moves to
using anonymous references for the links in the experimental extensions
section.

As we already do `unsigned Opcode = Inst.getOpcode();`, we may as well
use that variable.

As of
https://github.com/riscv/riscv-isa-manual/commit/1f038182810727f5feca311072e630d6baac51da
in the riscv-isa-manual, Zfa is at version 0.2. Reviewing the commit
history for
zfa.tex
<https://github.com/riscv/riscv-isa-manual/commits/master/src/zfa.tex>
there are no relevant changes since 0.1. As such, we can simply
increment the version number.

This change also removes the claim in RISCVUsage that we implement a
"subset of" Zfa, as I believe this is no longer true. That sentence
previously incorrectly claimed we didn't implement fli.{h,s,d} (I
[corrected this a couple of weeks
ago](https://reviews.llvm.org/rG3d969191b277)) but I think should have
removed the "subset of" wording too.

As was noted during the review, we never added Zfa to the release notes.
This is corrected in this patch.

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

The patch will caused dead loop because of DAGCombiner's canonicalization:
  // (x + C) - y  ->  (x - y) + C
  // y - (x + C)  ->  (y - x) - C
  // (x - C) - y  ->  (x - y) - C
  // (C - x) - y  ->  C - (x + y)

This reverts commit b3529b5b.

The patch lowers vector rint/nearbyint like vp.rint/nearbyint.

Reviewed By: craig.topper

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