As described in [1][2], `-mtune=` is used to select the type of target
microarchitecture, defaults to the value of `-march`. The set of
possible values should be a superset of `-march` values. Currently
possible values of `-march=` and `-mtune=` are `native`, `loongarch64`
and `la464`.

D136146 has supported `-march={loongarch64,la464}` and this patch adds
support for `-march=native` and `-mtune=`.

A new ProcessorModel called `loongarch64` is defined in LoongArch.td
to support `-mtune=loongarch64`.

`llvm::sys::getHostCPUName()` returns `generic` on unknown or future
LoongArch CPUs, e.g. the not yet added `la664`, leading to
`llvm::LoongArch::isValidArchName()` failing to parse the arch name.
In this case, use `loongarch64` as the default arch name for 64-bit
CPUs.

And these two preprocessor macros are defined:
- __loongarch_arch
- __loongarch_tune

[1]: https://github.com/loongson/LoongArch-Documentation/blob/2023.04.20/docs/LoongArch-toolchain-conventions-EN.adoc
[2]: https://github.com/loongson/la-softdev-convention/blob/v0.1/la-softdev-convention.adoc

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

Summary:
This is supposed to be enabled to say that we want correct sqrt by
default.

Remove test hack that was accidentally pushed.

[OpenMP] [OMPT] [7/8] Invoke tool-supplied callbacks before and after target launch and data transfer operations

Implemented RAII objects, initialized at target entry points, that
invoke tool-supplied callbacks. Updated status of target callbacks as
implemented.

Depends on D127365

Patch from John Mellor-Crummey <johnmc@rice.edu>
With contributions from:
Dhruva Chakrabarti <Dhruva.Chakrabarti@amd.com>
Jan-Patrick Lehr <janpatrick.lehr@amd.com>

Reviewed By: jdoerfert, dhruvachak, jplehr

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

This implements P0009 std::mdspan ((https://wg21.link/p0009)

),
a multidimensional span with customization points for
layouts and data access.

Co-authored-by: Damien L-G <dalg24@gmail.com>

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

[Clang] use unsigned integer constants in unit-test | fixes build error on ppc64le-lld-multistage-test

Fixes:
    /home/buildbots/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:1526:11: warning: comparison of integer expressions of different signedness: ‘const unsigned int’ and ‘const int’ [-Wsign-compare]
    /home/buildbots/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:1526:11: warning: comparison of integer expressions of different signedness: ‘const long unsigned int’ and ‘const int’ [-Wsign-compare]

Reviewed By: cor3ntin

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

This reverts commit ef9ec4bb.

The changes broke several bots:
https://lab.llvm.org/buildbot/#/builders/176/builds/3408
https://lab.llvm.org/buildbot/#/builders/198/builds/4028
https://lab.llvm.org/buildbot/#/builders/197/builds/8491
https://lab.llvm.org/buildbot/#/builders/197/builds/8491

rocm-device-libs and llpc were avoiding using f64 sqrt
intrinsics in favor of their own expansions. Port the
expansion into the backend. Both of these users should be
updated to call the intrinsic instead.

The library and llpc expansions are slightly different.
llpc uses an ldexp to do the scale; the library uses a multiply.

Use ldexp to do the scale instead of the multiply.
I believe v_ldexp_f64 and v_mul_f64 are always the same number of
cycles, but it's cheaper to materialize the 32-bit integer constant
than the 64-bit double constant.

The libraries have another fast version of sqrt which will
be handled separately.

I am tempted to do this in an IR expansion instead. In the IR
we could take advantage of computeKnownFPClass to avoid
the 0-or-inf argument check.

Almost all permutations of the flags are potentially relevant.

When a function is declared in the same scope as a class with the same
name then the function hides that class. Currently this is done by a
single check after the main loop in LookupResult::resolveKind, but
this can give the wrong result when we have a using declaration in
multiple namespace scopes in two different ways:

 * When the using declaration is hidden in one namespace but not the
   other we can end up considering only the hidden one when deciding
   if the result is ambiguous, causing an incorrect "not ambiguous"
   result.

 * When two classes with the same name in different namespace scopes
   are both hidden by using declarations this can result in
   incorrectly deciding the result is ambiguous. There's currently a
   comment saying this is expected, but I don't think that's correct.

Solve this by checking each Decl to see if it's hidden by some other
Decl in the same scope. This means we have to delay removing anything
from Decls until after the main loop, in case a Decl is hidden by
another that is removed due to being non-unique.

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

Adds a TODO for checking inlinining opportunities while traversing
the users of the specialization arguments. This was brought up in
the review of D154852.

Since the spec doesn't describe these behaviors as invalid,
the llvm-mc should just make them take care by hardware.

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

Revert "[OpenMP] [OMPT] [7/8] Invoke tool-supplied callbacks before and after target launch and data transfer operations"

This reverts commit 00ccfcf9.

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

This patch allows constant folding of PHIs when estimating the user
bonus. Phi nodes are a special case since some of their inputs may
remain unresolved until all the specialization arguments have been
processed by the InstCostVisitor. Therefore, we keep a list of dead
basic blocks and then lazily visit the Phi nodes once the user bonus
has been computed for all the specialization arguments.

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

EHScopeStack doesn't seem to be intended for copy. It frees memory in
the destructor and doesn't have user-written copy c'tor and assignment
operator, so delete them to avoid using default ones which would do
wrong.

Reviewed By: aaron.ballman

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

The usage of the taint analysis is described through a command injection attack example.
It is explained how to make a variable sanitized through configuration.

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

Revert rGfae7b98c "[Support] Change SetVector's default template parameter to SmallVector<*, 0>"

This is failing on Windows MSVC builds:
llvm\unittests\Support\ThreadPool.cpp(380): error C2440: 'return': cannot convert from 'Vector' to 'std::vector<llvm::BitVector,std::allocator<llvm::BitVector>>'
        with
        [
            Vector=llvm::SmallVector<llvm::BitVector,0>
        ]

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

This adds support for the LoongArch ELF psABI v2.00 [1] relocation
model to LLD. The deprecated stack-machine-based psABI v1 relocs are not
supported.

The code is tested by successfully bootstrapping a Gentoo/LoongArch
stage3, complete with common GNU userland tools and both the LLVM and
GNU toolchains (GNU toolchain is present only for building glibc,
LLVM+Clang+LLD are used for the rest). Large programs like QEMU are
tested to work as well.

[1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html

Reviewed By: MaskRay, SixWeining

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

This patch adds the predicate-as-counter registers pn0-pn15 to the
list of supported registers used when writing inline assembly.

Tests added to

  clang/test/CodeGen/aarch64-sve-inline-asm.c

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

After implementation of "[Clang] Implement P2741R3 - user-generated static_assert messages"  (47ccfd7a) the c indexer crashes when handling a `static_assert` w/o any message.
This is caused by using `dyn_cast` to get the literal string, which isn't working on `nullptr`.

Reviewed By: cor3ntin

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

This extends the existing 'arm_sme.tile_store' op to support all tile
sizes and adds a new op 'arm_sme.tile_load', as well as lowerings from
vector -> custom ops and custom ops -> intrinsics. Currently there's no
lowering for i128.

Depends on D154867

Reviewed By: awarzynski, dcaballe

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

IsARMBIgEndian function returns true only if:
  1. The triples are either arm or thumb and the
     commandline has the  option -mbig-endian
  2. The triples are either armeb or thumbeb.

Missing the checking of arm or thumb triples in the
first case pass through the --be8 endian flag to
linker For AArch64 as well which is not expected.
This is the regression happened from the previous
patch https://reviews.llvm.org/D154786.

It is better to refactor to only call IsARMBigEndian
for isARM and isthumb satisfying conditions which
keeps ARM and AArch64 separate.

Reviewed By: MaskRay

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

[RISCV] Merge rv32/rv64 vector narrowing integer right shift intrinsic tests that have the same content. NFC.

/Users/jiefu/llvm-project/llvm/lib/Target/AMDGPU/AMDGPUMachineCFGStructurizer.cpp:2603:10: error: variable 'CNI' set but not used [-Werror,-Wunused-but-set-variable]
    auto CNI = CI;
         ^
1 error generated.

Similar to D156016 for MapVector.