LLVM_TOOL_LLD_BUILD is a relic of the pre-monorepo times. This causes us to never set COMPILER_RT_HAS_LLD.

Instead, set it from the runtimes build if lld is being built and lld is used as the compiler-rt linker.

Mark a test that requires libstdc++ as requiring Android, as other platforms may not have a libstdc++ lying around.

Reviewed By: MaskRay

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

Add a DAG combine to form these from FADD_VL/FSUB_VL and FP_EXTEND_VL.

This makes it similar to other widening ops and allows us to handle
using the same FP_EXTEND_VL for both operands.

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

Preparation for D151969 which adds an FP version.

Instead of having a map from ConstString to StructuredDataPluginSP, we
can use an llvm::StringMap. The keys themselves don't need to be
ConstStrings, so an llvm::StringMap feels most natural.

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

Having both UBSan with the minimal runtime and KCFI enabled can be
useful in low-level software. As there are no conflicts between the
flags, add KCFI to the list of compatible sanitizers.

This patch deprecates StringRef::{starts,ends}with_insensitive as
their uses have migrated to {starts,ends}_with_insensitive,
respectively.

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

These functions have been deprecated since:

  commit 0f52c1f8
  Author: Kazu Hirata <kazu@google.com>
  Date:   Tue Feb 14 09:52:36 2023 -0800

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

These functions have been deprecated since:

  commit b49b429f
  Author: Kazu Hirata <kazu@google.com>
  Date:   Sun Feb 12 21:42:07 2023 -0800

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

StringRef was made to be passed by value efficiently.

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

Don't parse/handle mmap events with "(deleted)" filename.

Reviewed By: #bolt, rafauler

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

This should be last of the "bottom-up conversions" of various demanglers
to accept std::string_view.  After this, D149104 may be revisited.

Reviewed By: MaskRay

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

This patch fixes:

  clang/lib/Sema/SemaExprCXX.cpp:5591:3: error: default label in
  switch which covers all enumeration values
  [-Werror,-Wcovered-switch-default]

Had a couple of issues lately causing corrupted strings due to
problematic str_offsets (overflow due to >4GB .debug_str.dwo section in
a dwp and the dwp tool silently overflowing the 32 bit offsets updated
in the .debug_str_offsets.dwo section, and then more recently two CUs in
a dwo caused the dwp tool to reapply the offset adjustment twice
corrupting str_offsets.dwo as well) - so let's check that the offsets
are valid.

This assumes no suffix merging - if anyone implements that, then this
checking should just be removed for the most part (we could still check
the offsets are within the bounds of .debug_str[.dwo], but nothing more
- any offset in the range would be valid, the offsets wouldn't have to
land at the start of a string)

In many places we're using uint32_t where we should be using size_t.
We should be consistent.

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

Ensure that the expected location directives are from different sections.

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

These don't really need to be in the ConstString StringPool. I've
changed the return type to StringRef because on llvm.org and downstream
in the swift fork, this returns a constant value. We could change it to
return a std::string or something else if it needs to be able to change
between calls.

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

Apparently this test didn't actually test anything other that the IR compiles.

In InitElement() in flang/lib/Semantics/data-to-inits.cpp, don't
assume that values_.Location() can be called until after it has been
verified that values_.IsAtEnd() is not true.

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

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

i16/f16/bf16 will use the same .b16 registers and
i32/v2f16 and v2bf16 will share .b32 registers.

The changes are mostly mechanical, intended to remove unnecessary register
classes which tend to produce redundant register moves.

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

v2f16 regtype conversion to i32

Reviewed By: erichkeane, nickdesaulniers

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

db7cc034 added OpenMP support to the execution engine but didn't
add the explicit CMake dependency.

We've observed that the MLIR Jit Engine fails when the `omp` dialect is used due to a failure to register OpenMP-related translations. This small patch addresses this issue.

Reviewed By: mehdi_amini

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

Trusty runs in memory constrained environments, with many apps
having only one page (4KB) of heap memory available. However, we
still want to mmap() multiples of PAGE_SIZE at a time.

Additionally, switch Scudo from using sbrk() to mmap().

Reviewed By: cferris

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

Addresses the issue found by:
https://lab.llvm.org/buildbot/#/builders/30/builds/35886

Contribute a grammar, along with associated tests, from the upstream
project maintained at https://github.com/artagnon/tree-sitter-mlir. The
new grammar includes several fixes, and successfully parses 60-80% of
MLIR tests in the Arith, Math, ControlFlow, SCF, Tensor, Affine, and
Linalg dialects.

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

This commit fixes "TextDiagnostic::emitIncludeLocation" when compiling
with "-fdiagnostics-absolute-paths" flag enabled by emitting the absolute
path of the included file.

Fixes #63026

Reviewed By: aaron.ballman

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

Since all the type traits up until now have had Boolean vaules, we've
always been able to assume that the expressions are `bool`. This is
about to change (D151952 introduces a trait that returns `size_t`), so
we need to restructure the code so it doesn't become unwieldy.

This is achieved by giving traits a designated "return" type.

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

Map `ieee_fma` intrinsic to LLVM IR as `llvm.fma`.

Reviewed By: klausler

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

Three new transforms:
    1) `(icmp pred (shl nsw nuw X, Y), C)` [if `C <= 0`] -> `(icmp pred X, C)`
        - ugt: https://alive2.llvm.org/ce/z/K_57J_
        - sgt: https://alive2.llvm.org/ce/z/BL8u_a
        - sge: https://alive2.llvm.org/ce/z/yZZVYz
        - uge: https://alive2.llvm.org/ce/z/R4jwwJ
        - ule: https://alive2.llvm.org/ce/z/-gbmth
        - sle: https://alive2.llvm.org/ce/z/ycZVsh
        - slt: https://alive2.llvm.org/ce/z/4MzHYm
        - sle: https://alive2.llvm.org/ce/z/fgNfex
        - ult: https://alive2.llvm.org/ce/z/cXfvH5
        - eq : https://alive2.llvm.org/ce/z/sZh_Ti
        - ne : https://alive2.llvm.org/ce/z/UrqSWA

    2) `(icmp eq/ne (shl {nsw|nuw} X, Y), 0)` -> `(icmp eq/ne X, 0)`
        - eq+nsw: https://alive2.llvm.org/ce/z/aSJN6D
        - eq+nuw: https://alive2.llvm.org/ce/z/r2_-br
        - ne+nuw: https://alive2.llvm.org/ce/z/RkETtu
        - ne+nsw: https://alive2.llvm.org/ce/z/8iSfW3

    3) `(icmp slt (shl nsw X, Y), 0/1)` -> `(icmp pred X, 0/1)`
       `(icmp sgt (shl nsw X, Y), 0/-1)` -> `(icmp pred X, 0/-1)`
        - slt: https://alive2.llvm.org/ce/z/eZYRan
        - sgt: https://alive2.llvm.org/ce/z/QQeP26

    Transform 3) is really sle/slt/sge/sgt with 0, but sle/sge
    canonicalize to slt/sgt respectively so its implemented as such.

Reviewed By: nikic

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

Reviewed By: nikic

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

Reviewed By: aartbik

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

A variable declared with __attribute__((cleanup)) cannot be unused, as
its address is passed to the clean up function. Do not emit
-Wunused-variable for variables declared with the cleanup attribute,
which matches GCC's behavior: https://godbolt.org/z/dz5YfTsan

Reviewed By: erichkeane, nickdesaulniers

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

Simplify D99750 by factoring out a utility which we already have multiple instances of in tree.

Several OCaml modules using the old PassManager API were removed in
https://reviews.llvm.org/D144751, but the META file still needed to be
updated to remove them. This diff also removes an unused macro definition
related to the module removals.

Reviewed By: nikic

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

This reverts commit 6a2e0cb4.

Define the function @llvm.amdgcn.make.buffer.rsrc, which take a 64-bit
pointer, the 16-bit stride/swizzling constant that replace the high 16
bits of an address in a buffer resource, the 32-bit extent/number of
elements, and the 32-bit flags (the latter two being the 3rd and 4th
wards of the resource), and combines them into a ptr addrspace(8).

This intrinsic is lowered during the early phases of the backend.

This intrinsic is needed so that alias analysis can correctly infer
that a certain buffer resource points to the same memory as some
global pointer. Previous methods of constructing buffer resources,
which relied on ptrtoint, would not allow for such an inference.

Depends on D148184

Reviewed By: arsenm

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

1. Remove the existing code that would encode the constant offsets (if
there were any) on buffer intrinsic operations onto their
`MachineMemOperand`s. As far as I can tell, this use of `offset` has
no substantial impact on the generated code, especially since the same
reasoning is performed by areMemAccessesTriviallyDisjoint().

2. When a buffer resource intrinsic takes a pointer argument as the
base resource/descriptor, place that memory argument in the value
field of the MachineMemOperand attached to that intrinsic.

This is more conservative than what would be produced by more typical
LLVM code using GEP, as the Value (for alias analysis purposes)
corresponding to accessing buffer[0] and buffer[1] is the same.
However, the target-specific analysis of disjoint offsets covers a lot
of the simple usecases.

Despite this limitation, the new buffer intrinsics, combined with
LLVM's existing pointer annotations, allow for non-trivial
optimizations, as seen in the new tests, where marking two buffer
descriptors "noalias" allows merging together loads and stores in a
"load from A, modify loaded value, store to B" sequence, which would
not be possible previously.

Depends on D147547

Reviewed By: arsenm

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