Summary:
Right now the only way to force libc++abi tests to link with the static version of libc++abi is to set `LIBCXXABI_ENABLE_SHARED` to `OFF`. However, this doesn't work when libc++abi is built as standalone project because of [this](https://github.com/llvm/llvm-project/blob/54c522420347e58aa7bae1892cf5c5672b57c875/libcxxabi/CMakeLists.txt#L503-L519).

This change allows specifying the version of the library for tests to link with.

This is useful for remote testing, for example, with `SSHExecutor`, where we _have_ to link with libc++abi statically.

Two new CMake options are introduced here: `LIBCXXABI_LINK_TESTS_WITH_SHARED_LIBCXXABI` and `LIBCXXABI_LINK_TESTS_WITH_SHARED_LIBCXX`. They can be set to `OFF` to tell the test utility to link tests with the static libraries.

It shouldn't break anything, because the default values of these options are set such that the test utility will behave the same way.

Reviewers: EricWF, mclow.lists, phosek, mehdi_amini, ldionne, jroelofs, bcraig

Subscribers: mgorny, christof, ldionne, libcxx-commits

Tags: #libc

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

This is a special case of Z / (X / Y) => (Y * Z) / X, with X = 1.0.
The m_OneUse check is avoided because even in the case of the
multiple uses for 1.0/Y, the number of instructions remain the same
and a division is replaced by a multiplication.

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

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

This isn't too useful now, since nothing is currently trying to form
min/max from cmp+select.

These should now be limited to R600 code.

Partially fixes BFE pattern import.

This doesn't enable any new imports yet, but moves the fmed patterns
from failing on this to hitting the "complex suboperand referenced
more than once" limitation in tablegen.

Only partially fixes one pattern import.

Reduces diff for a future patch.

A lot of the IR-level intrinsics we've been defining for MVE recently
accidentally had `props = []` instead of `props = [IntrNoMem]`, so
that optimization would have been overcautious about reordering them.

All the affected cases were due to instantiating the multiclasses
`MVEPredicated` and `MVEMXPredicated` without filling in the `props`
parameter, because I //thought// I remembered having set the defaults
in those multiclasses to `[IntrNoMem]`. In fact I hadn't done that.
Now I have.

(The IR intrinsics that //do// read and write memory are all
explicitly marked as `[IntrReadMem]` or `[IntrWriteMem]` already, so
they will override these defaults.)

In common with most MVE immediate shift instructions, the left shift
takes an immediate in the range [0,n-1], while the right shift takes
one in the range [1,n]. I had absent-mindedly made them both the
latter.

While I'm here, I've added a set of regression tests checking both
ends of the immediate range for a representative sample of the
immediate shifts.

If we are extracting a chunk of a vector that's a fraction of an
operand of the concatenated vector operand, we can extract directly
from one of those original operands.

This is another suggestion from PR42024:
https://bugs.llvm.org/show_bug.cgi?id=42024#c2

But I'm not sure yet if it will make any difference on those patterns.
It seems to help a few existing AVX512 tests though.

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

Fix test failed by D43357 on Windows.

This is step 1 of damage control assuming that we need to remove several
over-reaching folds for select-of-booleans because they can cause
miscompiles as shown in D72396.

The scalar case seems obviously safe:
https://rise4fun.com/Alive/jSj

And I don't think there's any danger for vectors either - if the
condition is poisoned, then the select must be poisoned too, so undef
elements don't make any difference.

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

Architecturally, it's allowed to have MVE-I without an FPU, thus
-mfpu=none should not disable MVE-I, or moves to/from FP-registers.

This patch removes `+/-fpregs` from features unconditionally added to
target feature list, depending on FPU and moves the logic to Clang
driver, where the negative form (`-fpregs`) is conditionally added to
the target features list for the cases of `-mfloat-abi=soft`, or
`-mfpu=none` without either `+mve` or `+mve.fp`. Only the negative
form is added by the driver, the positive one is derived from other
features in the backend.

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

Patch by: @raghesh (Raghesh Aloor)

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

instead of a function pointer + void*, take a std::function. This
removes a bunch of repetitive, unsafe void* casts.

This patch fixes a test failure on a non-intel (PowerPC64) box.
The two affine.load are independent and hence llvm may reorder them.
The CHECK lines are modified for supporting reordered case.

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

Function trailing requires clauses now parsed, supported in overload resolution and when calling, referencing and taking the address of functions or function templates.

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

Add a comment describing the dependencies of the pass.

Use cast<> instead of dyn_cast<> since we know that the pointer should be valid (and is dereferenced immediately).

Use cast<> instead of dyn_cast<> since we know that the pointer should be valid (and is dereferenced immediately below).

Summary:
Our code was expecting that a single (symbol) file contains only one
kind of location lists. This is not correct (on non-apple platforms, at
least) as a file can compile units with different dwarf versions.

This patch moves the deteremination of location list flavour down to the
compile unit level, fixing this problem. I have also tried to rougly
align the code with the llvm DWARFUnit. Fully matching the API is not
possible because of how lldb's DWARFExpression lives separately from the
rest of the DWARF code, but this is at least a step in the right
direction.

Reviewers: JDevlieghere, aprantl, clayborg

Subscribers: dblaikie, lldb-commits

Tags: #lldb

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

Summary:
A skeleton unit can easily be detected by checking the m_dwo_symbol_file
member, but we cannot tell a split unit from a normal unit from the
"inside", which is sometimes useful.

This patch adds a m_is_dwo member to enable this, and align the code
with llvm::DWARFUnit. Right now it's only used to avoid creating a split
unit inside another split unit (which removes one override from
SymbolFileDWARFDwo and brings us a step closer to deleting it), but my
main motivation is fixing the handling of location lists in mixed v4&v5
files. This comes in a separate patch.

Reviewers: JDevlieghere, aprantl, clayborg

Subscribers: dblaikie, lldb-commits

Tags: #lldb

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

Use castAs<> instead of getAs<> since the pointer is dereferenced immediately below and castAs will perform the null assertion for us.

Assert that the pointers are non-null before dereferencing them.

We don't unroll vector loops for MVE targets, but we miss the case
when loops only contain intrinsic calls. So just move the logic a
bit to catch this case.

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

Summary: In D72333 we've introduced support for `if constexpr` but the test for uninstantiated template was not ready to land on windows platform since this target uses `-fdelayed-template-parsing` by default. This patch addresses this by passing `-fno-delayed-template-parsing` to the test.

Reviewers: JonasToth

Subscribers: xazax.hun, cfe-commits

Tags: #clang

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

The command here failed due to the type in 'create' but the expect
did not actually check for the error message. This fixes the typo
and adds a check for the actuall error message we should see.

This patch updates the shape propagation to iterate until no new shape
information is discovered.

As initial seed for the forward propagation, we use the matrix intrinsic
instructions. Both propagateShapeForward and propagateShapeBackward
return new work lists, with the instructions to be used for the next
iteration. When propagating forward, we record all instructions we added
new shape information for. When propagating backward, we record all
users of instructions we added new shape information for.

Reviewers: anemet, Gerolf, reames, hfinkel, andrew.w.kaylor

Reviewed By: anemet

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

Summary: Improves basic hover presentation logic to include more info.

Reviewers: sammccall

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

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