Move a few supporting routines for generating function calls to CodegenUtils so
that they can be used by the codegen path for sparse tensor file input and
output.

Reviewed By: aartbik

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

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

The LIT test cases were migrated with the script provided by
Nikita Popov.

No manual changes were made. Committed without review since
no functional changes, after consultation with uweigand.

This differential comprises three related changes: (1) it gives SparseTensorCOO standard C++-style iterators; (2) it removes the old iterator stuff from SparseTensorCOO; and (3) it introduces SparseTensorIterator which behaves like the old SparseTensorCOO iterator stuff used to.

The SparseTensorIterator class is needed because the MLIR codegen cannot easily use the C++-style iterators (hence why SparseTensorCOO had the old iterator stuff).  Distinguishing SparseTensorIterator from SparseTensorCOO also helps improve API hygiene since these two classes are used for distinct purposes.  And having SparseTensorIterator as its own class enables changing the underlying implementation in the future, without needing to worry about updating all the codegen tests etc.

Reviewed By: aartbik

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

Performing a load before calling __cxa_guard_acquire is supposed to be
an optimization, but it isn't much of one if we're just going to emit a
call to __atomic_load_1 instead.  Instead, just skip the load, and
let __cxa_guard_acquire do whatever it wants.

(In practice, on such targets, the C++ library is just built with
threading turned off, so the result isn't actually threadsafe, but
there's not really anything clang can do about that.)

The alternative here is that we try to define some ABI for threadsafe
init that allows the speculative load without full atomics.  Almost any
target without full atomics has a load that's s "atomic enough" for this
purpose. But it's not clear how we emit an "atomic enough" load in LLVM
IR, and there isn't any ABI document we can refer to.

Or I guess we could turn off -fthreadsafe-statics by default on
Cortex-M0, but that seems like it would be surprising.

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

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

Commit `371883f4` caused a noticeable compile-time regression (about 0.4% geomean at -O0):
http://llvm-compile-time-tracker.com/compare.php?from=92233159035d1b50face95d886901cf99035bd99&to=371883f46dc23f8464cbf578e2d12a4f92e61917&stat=instructions

To address this switch `Scope::DeclSetTy` back to a `SmallPtrSet` and change `Sema::ActOnPopScope` to explicitly order the diagnostics that this function emits.

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

Make sure we propagate the value for `IsArrow` to
`RebuildExtVectorElementExpr` in order to be able to handle correctly
vector component accesses where the base value is a pointer.

Reviewed By: rjmccall

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

We don't use the "instantiate" word for the macro expansion in LLVM,
see c9c8419c.

Libcxx gdb pretty printers were disabled due to an old version
of gdb in the release testing. This reenables them, and fixes
various bit rot issues from not running them.

This adds infrastructural pieces for an analysis to compute the DXIL
shader flags. In this state the analysis can compute two fairly
straightforward feature flags for use of double-precision floating
point values and the DX 11.1 extended double support.

This patch does conflict with D135190, conflicts will be resolved prior
to merging.

Reviewed By: python3kgae

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

# Conflicts:
#	llvm/lib/Target/DirectX/CMakeLists.txt
#	llvm/lib/Target/DirectX/DirectXTargetMachine.cpp

We already had the ability to do that for libc++.dylib, so this only adds
consistency for all the runtime libraries. This should allow working around
difficulties on AIX as described in https://llvm.org/D134221.

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

Just like we install libc++ and libc++abi headers by default when we
install the library, it makes sense to install the libunwind headers
by default when we build libunwind. In the current state of things,
there is an increased risk that folks are using older (previously
installed) libunwind headers along with a recent libunwind dylib,
which is not ideal.

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

Summary:
A previous patch ensured that we can't use `-foffload-lto` with CUDA in
non-RDC mode. This did not correctly check for if we were actually
offloading to CUDA so it ended up preventing us from using LTO for
OpenMP.

Summary:
This patch adds an entry to the FAQ that shows how to link CUDA with
OpenMP.

Summary:
This option forwards a clang flag with a `-no` variant to the Clang
compiler. It should use the `hasFlag` so it works properly when the
option is overridden.

Summary:
This patch adds some documentation in the FAQ regarding
multi-architecture binary support using the `--offload-arch` flag.

Print unsupported types on match failures.

Suggested by @Mogball and @jpienaar in D135204.

Reviewed By: Mogball

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

Similar to D135170.

Reviewed By: DavidSpickett

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

[AMDGPU] Make the uses_dynamic_stack field in the kernel descriptor and the metadata map specific to code object v5 and later

Unfortunately, we have a broken handling of this in the runtime of rocm
5.3. The runtime is expected to handle this correctly when v5 becomes
the default.

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

correlates the option with reponse file concept.

Reviewed By: HazardyKnusperkeks

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

The LIT test cases were migrated with the script provided by
Nikita Popov. Due to the size of the change it is split into
several parts.

Reviewed By: nemanja, nikic

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

The LIT test cases were migrated with the script provided by
Nikita Popov. Due to the size of the change it is split into
several parts.

Reviewed By: nemanja, amyk, nikic, PowerPC

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

This is mainly to improve the readability of the tests. As a side
effects the tests run faster too,

Reviewed By: ldionne, #libc

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

This matches patterns of the form

```
(X op Y) == X
```

And transforms them to

```
Y == 0
```

where appropriate.

Example: https://godbolt.org/z/hfW811c7W

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

The previous code used a APInt(1, 0) to represent the demanded elts of a scalable vector, and then ignored that argument if type was scalable.  This was inconsistent with the UndefElts parameter which is set to either APInt(1, 0) or APInt(1,1) - that is, implicitly broadcast across all lanes.  Particularly since the undef code relied on the DemandedElts parameter having bitwidth 1 to achieve that result!

This change switches the demanded parameter to APInt(1,1), documents the broadcast semantics, and takes advantage of it to remove one special case for scalable vectors which is no longer required.

A new EnumArgument ResourceKind is added for HLSLResourceAttr.
This will be use to get resource kind instead of parse it from the type name.

Reviewed By: aaron.ballman

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

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

Make support more generic to support future instructions.
Currently NFC.

Reviewed By: foad, arsenm

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

Ran:

    git ls-files '*.gn' '*.gni' | xargs llvm/utils/gn/gn.py format

Simply folds away bitcasts that cancel each other.

Reviewed By: arsenm

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

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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