This test fails on clang-18.

When commuting the operands, don't create a constant expression
for undesirable binops. Only invoke the constant folding function
in that case.

This is a preparation for ARM64EC/ARM64X binaries, which may contain both ARM64
and x86_64 code in the same file. llvm-objdump already has partial support for
mixing disassemblers for ARM thumb mode support. However, for ARM64EC we can't
share MCContext, MCInstrAnalysis and PrettyPrinter instances. This patch
provides additional abstraction which makes adding mixed code support later in
the series easier.

Reviewed By: jhenderson, MaskRay
Differential Revision: https://reviews.llvm.org/D149093

CUDA allows replacing standard math functions with less accurate
native math functions when -use_fast_math is specified
(https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#intrinsic-functions).
Cuda-clang does this when -fcuda-approx-transcendentals
or -ffast-math is specified. HIP-clang currently passes option
-fcuda-approx-transcendentals to clang -cc1 and predefines
__CLANG_CUDA_APPROX_TRANSCENDENTALS__ but does
not replace standard math functions with native math functions.

This patch implements this in a similar approach as cuda-clang.

Reviewed by: Brian Sumner, Matt Arsenault

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

C99 is the the earliest C version provided by the language opt.

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

Guard FoldBranchToCommonDest in SimplifyCFG with the SpeculateBlocks
flag as it can also speculate instructions.

This was split out of D155997.

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

start with example usage, predefined macros, and path setting.

Reviewed by: Brian Sumner, Siu Chi Chan, Matt Arsenault, Ronan Keryell

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

Recover the checking for the default language standard for C++.

Reviewed by: Douglas Yung, Paul Robinson

This reapplies the change for and, but also marks or as undesirable
at the same time. Only handling one of them can cause infinite
combine loops due to the asymmetric handling.

-----

In preparation for removing support for and/or expressions, mark
them as undesirable. As such, we will no longer implicitly create
such expressions, but they still exist.

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