The main op implementation file for SPIR-V grew past 5k LOC. This makes it
take a long time to compile and index with LSPs like clangd.

Pull out the first few SPIR-V extension ops into their own `.cpp` files,
just like we do with `.td` op definitions. This includes the
KHR/NV/Intel coop matrix and the integer dot prod extensions.

I plan to further split this in future revisions.

Reviewed By: antiagainst

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

Correct link in release notes and format of some notes.

Fix the various complex libm selection logic issues from D155310:
- disableMlirComplex is set to false. This means that using mlir complex
is enabled. Yet, the current code still selects libm.
- If we enable mlir complex, we should not check if use approx is
enabled. Namely, we should use mlir complex either if we enable mlir
complex OR use approx is enabled.

To fix the issues, we flip the logic of `disableMlirComplex` to enable
instead. We set it to false by default since the intention from D155310
is to use libm by default. Then we use a logical `&&` with use approx
so that we select libm when BOTH mlir complex and use approx are
disabled.

Reviewed By: vzakhari

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

Summary:
Simple cleanup of the interface so we do not depend on the installed
headers and get everything we need just including rpc_client.h.

Add summary and synthetic data formatters for `llvm::DenseMap`.

This implementation avoids expression evaluation by using a heuristic. However, as
heuristics go, there is a corner case: A single deleted entry (a single "tombstone"),
will result in a child value with an invalid key but a valid value.

Instead of calling `getEmptyKey()` and `getTombstoneKey()` to determine which buckets
are empty, and which contain real key-values, the heuristic scans all buckets to
identify keys that exist only once. These singleton keys are considered valid.

The empty key will always exist multiple times. However the tombstone key may exist
zero, one, or many times. The heuristic has no problems when there are zero or many
tombstones, but when there is exactly one deleted entry (one tombstone), then the
heuristic will incorrectly identify it as valid.

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

This is an alternative to D155288 that can handle other sources of
xori like FP compares. Unfortunately, it misses the i64 setge case
on RV32 in condops.ll.

Reviewed By: asb

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

This fixes some warnings (that were caught as errors) in https://reviews.llvm.org/D155518/.

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

This change is mostly for brevity's sake; but it also paves the way for the `Policy` enum to be reuseable for other situations that require the same three-way semantics.

Reviewed By: Peiming

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

These tests break with msan on the sanitizer-aarch64-linux-bootstrap-msan
builder. Note the x86_64 builder is not affected. To unbreak the CI
temporary disable the tests completely with msan.

The breakage was introduced by D150044.

Link time thinLTO spawns pthreads to parallelize optimization and
codegen of the input bitcode files. On AIX, the default pthread
stack size limit is ~192k for 64-bit programs; insufficient for a
normal LLVM compilation.

Reviewed By: ZarkoCA, MaskRay

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

Need to check for FixedVectorType, not a vector type, since later
compiler performs unconditional cast to FixedVectorType and gets the
number of elements in this type.

This is primarily used for .rodata.cst* duplicate elimination. The
sections are usually much smaller than .debug_str (D154813), so the
speedup is negligible. We do this switch for consistency as we want to
eliminate xxh64 in lld.

Detail:
LD64 uses the name provided via  -[dylib]install_name as "Identifier", when available.
For compatiblity, LLD should do that too.

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

This patch adds some information that we have support for in the OpenMP
clang support page.

Reviewed By: jdoerfert

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

MSAN wrappers can be inserted for e.g. the access to stderr in the
constructor of the test, which can segfault if the constructor function
runs before these data structures have been initialized.

Reviewed By: dvyukov

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

Similar to combineVectorSignBitsTruncation, we don't require all-signbits source inputs, just enough signbits to reach into the lowest i16 to safely use PACKSSDW.

Refactor to use BasicBlockUtils functions and make life easier for
a subsequent patch for updating the dominator tree.

Reviewed By: dmgreen

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

/scratch/powerllvm/powerllvm_env/aix-ppc64/clang-ppc64-aix/llvm-project/compiler-rt/lib/profile/InstrProfilingPlatformAIX.c:202:40: error: cast from 'const int (*)[0]' to 'void *' drops const qualifier [-Werror,-Wcast-qual]
                               (void *)&dummy_name, (void *)&dummy_vnds};
                                       ^
1 error generated.

TL;DR the following API functions have been merged

```
void populateFoldUnitExtentDimsViaReshapesPatterns(RewritePatternSet &patterns);
void populateFoldUnitExtentDimsViaSlicesPatterns(RewritePatternSet &patterns);
```

into

```
void populateFoldUnitExtentDimsPatterns(RewritePatternSet &patterns,
                                        ControlDropUnitDims &options);
```

To use the previous functionality use

```
ControlDropUnitDims options;
// By default options.rankReductionStrategy is
// ControlDropUnitDims::RankReductionStrategy::ReassociativeReshape.
populateFoldUnitExtentDimsPatterns(patterns, options);
```

and

```
ControlDropUnitDims options;
options.rankReductionStrategy = ControlDropUnitDims::RankReductionStrategy::ExtractInsertSlice
populateFoldUnitExtentDimsPatterns(patterns, options);

```

This pass is quite old and needed to be updated based on the current
approach to transformations in Linalg

- Instead of two patterns, one to ju...

Starting from AIX 7.2 TL5 SP6 and AIX 7.3 TL2 the system linker supports thinLTO.

Reviewed By: ZarkoCA, MaskRay

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

Allow the init and combiner regions to have more
arguments to pass information.

Reviewed By: razvanlupusoru

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

As requested on D155647.

Fixes: https://github.com/llvm/llvm-project/issues/63956

Add a more "flexible" `SplitBlockAndInsertIfThenElse` function
and re-implement some others on top of it.

Reviewed By: dmgreen

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

All data structures and values associated with handling virtual functions / inheritance, as well as RTTI, are globals and thus can only reside in the global address space. This was not taken fully taken into account because for most targets, global & generic appear to coincide. However, on targets where global & generic ASes differ (e.g. AMDGPU), this was problematic, since it led to the generation of invalid bitcasts (which would trigger asserts in Debug) and less than optimal code. This patch does two things:

ensures that vtables, vptrs, vtts, typeinfo are generated in the right AS, and populated accordingly;
removes a bunch of bitcasts which look like left-overs from the typed ptr era.

Reviewed By: yxsamliu

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

This has been ratified according to https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions

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

xxh3 is substantially faster than xxh64.
For lld/ELF, there is substantial speedup in `.debug_str` duplicate
elimination (D154813). Use xxh3 for lld-macho as well.

Reviewed By: #lld-macho, oontvoo

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

xxh3 is substantially faster than xxh64.
For lld `.debug_str` there is substantial speedup (D154813).

@avl reports that it is around 1-2% improvement for different number of input sets and for different threads configuration.

Reviewed By: avl

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

The indirection here is for some reason causing an unnecessary
constructor. If we leave this uninitialized we will get the default
constructor which simply zero initliaizes the global. I've checked the
output and confirmed that it uses the `zeroinitializer` so this should
be safe.

Reviewed By: JonChesterfield

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

A vmv.v.v shares the same encoding as a vmerge that isn't masked, so we can
also fold it into its operands if we treat it as a vmerge with an all-ones
mask.  We take care here not to actually transform the existing vmv into a
vmerge, otherwise things like True.hasOneUse() become inaccurate. Instead this
just returns an equivalent list of operands.
This is an alternative to D153351.

Reviewed By: reames

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

Currently when folding vmerge into its operands, we stop if the VLs aren't
identical.  However since the body of (vmerge (vop)) is the intersection of
vmerge and vop's bodies, we can use the smaller of the two VLs if we know it
ahead of time.  This patch relaxes the constraint on VL if they are both
constants, or if either of them are VLMAX.

Reviewed By: reames

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

Reviewed By: reames

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

A comma is missing which is incorrect if macro is used.

Reviewed By: clementval

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