Get rid of non-constant and undef indices of insertelements
at `buildTree()` stage. Fix bugs.

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

This patch updates the handling of vectors in getPreferredVectorAction():

For single-element and scalable vectors, fall back to default vector legalization
handling. For vNi1 vectors, add handling to either split or promote them in
order to prevent the production of wide v256i1/v512i1 types.

The following assertion is fixed by this patch, as we ended up producing the
wide vector types (that are used for MMA) in the backend prior to this fix.

```
Assertion failed: VT.getSizeInBits() == Operand.getValueSizeInBits() &&
"Cannot BITCAST between types of different sizes!"
```

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

(cherry picked from commit ac5a5a9c)

While matching widening multiply, if we matched an extend from i8->i32,
i16->i64 or i8->i64, we need to reintroduce a narrower extend. If we're
matching a vwmulsu we need to use a sext for op0 and a zext for op1.

This bug exists in LLVM 14 and will need to be backported.

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

(cherry picked from commit 478c237e)

This is a simplified c12d49c4 in main
which just fixes the bug but does not affect the -O2 deduplication.

For the release/14.x branch.

Reviewed By: tstellar

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

This patch added the MC layer support of Zfinx extension.

Authored-by: StephenFan
Co-Authored-by: Shao-Ce Sun

Reviewed By: asb

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

(cherry picked from commit 7798ecca)

It is necessary to guard atomic_double type according to
https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#_footnotedef_54.
Platform that disable cl_khr_int64_base_atomics and
cl_khr_int64_extended_atomics will have compiling errors even if
atomic_double is not used.

Patch by Haonan Yang.

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

(cherry picked from commit 477bc8e8)

The clang-analyzer plugins are not linked to a particular tool, so they
can only be compiled if plugins are broadly supported. We could opt
instead to decide whether to link them to specifically against clang or
with undefined symbols, depending on the value of LLVM_ENABLE_PLUGINS,
but we do not currently expect there to be a use case for that rather
niche configuration.

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

(cherry picked from commit 9d59cfc6)

This patch refines the logic to determine grid size as previous method
can escape the check of whether `CudaBlocksPerGrid` could be greater than the actual
hardware limit.

Reviewed By: jdoerfert

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

(cherry picked from commit f6685f77)

Debuginfod can pull in libcurl as a dependency, which isn't appropriate
for libLLVM. (See
https://gitlab.freedesktop.org/mesa/mesa/-/issues/5732).

This change breaks out debuginfod into a separate non-component library
that can be used directly in llvm-symbolizer. The tool can inject
debuginfod into the Symbolizer library via an abstract DebugInfoFetcher
interface, breaking the dependency of Symbolizer on debuinfod.

See https://github.com/llvm/llvm-project/issues/52731

Reviewed By: phosek

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

The test diffs are identical to D119111.

This only affects x86 currently because no other target
has an override for the TLI hook that controls this transform.

(cherry picked from commit 905abc5b)

(cherry picked from commit 24562bab)

Otherwise, the warnings always trigger.

(cherry picked from commit 2e3bb910)

As suggested in https://reviews.llvm.org/D112155.

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

(cherry picked from commit 641a141d)

Reflect the latest achievements in clang docs.

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

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

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

This is to avoid spurious test failures in case apple-clang-14 doesn't
support _BitInt.

(cherry picked from commit 87b218b4)

Reported by Stefan Pintilie in D119773.

For a branch to a hidden undefined weak symbol, there is an
`assert(sym->getVA());` failure in PPC64LongBranchTargetSection::writeTo for a
-no-pie link. The root cause is that we unnecessarily create the thunk for the
-no-pie link.

Fix this by changing the condition to just `s.isUndefined()`. See the inline
comment.

Rename ppc64-weak-undef-call.s to ppc64-undefined-weak.s to be consistent with
other architectures.

Reviewed By: sfertile, stefanp

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

(cherry picked from commit 53b59fdc)

Also, fix the actual code so that the test would pass if we fixed the
issue that the method is instantiated in the dylib, and hence the debug
assertion will never fire except if the debug mode is enabled when the
dylib is being compiled.

(cherry picked from commit 5c53afe5)

This works around a known issue in ASan. ASan doesn't instrument weak
symbols. Because instrumentation increases object size, the binary can
end up with two versions of the same object, one instrumented and one
not instrumented, with different sizes, which ASan will report as an ODR
violation. In libc++, this affects typeinfo for `std::bad_function_call`
which is emitted as a weak symbol in the test executable and as a strong
symbol in the shared library.

The main open issue for ASan appears to be
https://github.com/google/sanitizers/issues/1017.

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

(cherry picked from commit 10953974)

This wasn't caught because we don't test the combination of no-filesystem
and no-experimental-features in the CI.

(cherry picked from commit 7dad5f84)

The logic here is that we are disabling *only* things in `std::ranges::`.
Everything in `std::` is permitted, including `default_sentinel`, `contiguous_iterator`,
`common_iterator`, `projected`, `swappable`, and so on. Then, we include
anything from `std::ranges::` that is required in order to make those things
work: `ranges::swap`, `ranges::swap_ranges`, `input_range`, `ranges::begin`,
`ranges::iter_move`, and so on. But then that's all. Everything else (including
notably all of the "views" and the `std::views` namespace itself) is still
locked up behind `_LIBCPP_HAS_NO_INCOMPLETE_RANGES`.

Originally reviewed as https://reviews.llvm.org/D118736.

(cherry picked from commit 53406fb6)

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

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

If we assume `llvm.amdgcn.s.barrier` is aligned we may remove it and
cause OpenMP GPU applications on the AMD GPU to be stuck or wrongly
synchronized.

Reported by Carlo Bertolli.

(cherry picked from commit ede248e6)

If we had some source value we could infer an address space from that
went through a ptrtoint/inttoptr pair, this would fail since bitcast
can't change the address space.

Fixes issue 53665.

(cherry picked from commit 52fbb786)

For the release/14.x branch.

Reviewed By: alexander-shaposhnikov, jhenderson

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

As explained in the comment, we don't have macOS 10.15 builders anymore
in the fleet. Enabling those tests on the release branch would require
cherry-picking too many changes from `main`.

This reverts commit 5ebdb07e.

Enabling shrink wrap by default can cause assertions or crashes, and
these should first be investigated and fixed. For now, reverting the
change so it can be cherry-picked into 14.0.0 is the safest choice.

(cherry picked from commit 7af3d4ab)

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

(cherry picked from commit 287ce6b5)

This is an alternative to D118667 that instead of fixing the store
to match phase 1, it tries to detect the mismatch with the expected
value at the end of the block. This inserts a vsetvli after the vse
to satisfy the requirement of the other basic block.

We still have serious design issues in the pass, that is going to
require some rethinking.

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

(cherry picked from commit 541c9ba8)

Revert "[RISCV] Fix a vsetvli insertion bug involving loads/stores." and "[RISCC] Add missing words to comment. NFC"

This reverts commit f943c58c.
and commit 7eb78107.

This introduced a new bug that appears to be easier to hit.

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

(cherry picked from commit f35ac872)

We're missing a vsetvli before a vse after a redsum in this test.

This appears to be because the vmv.s.x has a VL of 1, but did not
trigger a vsetvli because it is a scalar move op and any non-zero
VL would work. So it looked at it the predecessors and decided it was
that they all had a non-zero vl. Then the redsum was visited, it
also took the VL from the predecessors since the vmv.s.x and the 4
was found compatible.

Finally we visit the vse and it looks at the BBLocalInfo and sees
that is compatible because it contains a VL of 1 from the vmv.s.x,
the first instruction in the block. BBLocalInfo was not updated
when the vredsum was visited because BBLocalInfo was valid and no
vsetvli was generated.

I think fundamentally the vmv.s.x optimization has the same first
phase and third phase not matching problem that D118667 was trying
to fix for stores.

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

(cherry picked from commit ba9a7ae7)

MSVC does not support variable length arrays. Replace with KMP_ALLOCA
which is already used in the same file for stack-allocated variables.

(cherry picked from commit 6be7c21b)

(cherry picked from 2937b282)

This reverts commit 0df52296.

Additional checks are added to fix the detection of the last memory region
in GetMemoryRegions or repeating the "memory region" command when the
target has non-address bits.

Normally you keep reading from address 0, looking up each region's end
address until you get LLDB_INVALID_ADDR as the region end address.
(0xffffffffffffffff)

This is what the remote will return once you go beyond the last mapped region:
[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
[0x0001000000000000-0xffffffffffffffff) ---

Problem is that when we "fix" the lookup address, we remove some bits
from it. On an AArch64 system we have 48 bit virtual addresses, so when
we fix the end address of the [stack] region the result is 0.
So we loop back to the start.

[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
[0x0000000000000000-0x000...

This patch fixes the issue that the for loop in `applyToShadowMapEntries`
is infinite because `Itr` is not incremented in `CB`. Fixes #53727.

Reviewed By: jdoerfert

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

(cherry picked from commit c27f530d)

Instead of using the deprecated LLVM_ENABLE_PROJECTS build, use the
default runtimes build. This is just as fast, but it's supported.

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

(cherry picked from commit f34f7dfe)