The FIXME comment here is not really correct. Also, handle the case of
non-primitive array element types differently, to reduce indentation.

If `-fuse-ld=lld` is specified but no user linker script is offered, we
try to use avr-libc's default one for lld. (not needed for GNU ld)

[ELF][test] Test relocations referencing weak symbol, which is defined relative to a section discarded by /DISCARD/

With this patch we no longer issue a warning for unused parameters which
are marked as such.

This fixes #68209

Don't use reserved identifier (_GroupBy)
Fix GCC 7.4/7.5 builds (return Filter => return std::move(Filter))
Remove trailing spaces

I've migrated all known uses of llvm::support::endianness to
llvm::endianness.  This patch removes the migration helpers.

This fixes an old FIXME comment. Almost all callers already classify()
the type anyway, so just pass the result of that
to visitZeroInitializer().

The current lowering of statepoints does not take into account return
attributes present on the `gc.result` leading to different code being
generated than if one were to not use statepoints. These return
attributes can affect the ABI which is why it is important that they are
applied in the lowering.

This also adds the .variant_pcs directive to some functions from which
it was previously missing.

We did not have a catch-all for when the two operand types are
identical after canonicalization. Instead, we handled that on a case by
case basis. Thus, we would diagnose code like:
```
mat4 test(int a) {
  typedef float mat4 __attribute((matrix_type(4, 4)));
  mat4 transform;
  return (a > 0) ? transform : transform;
}
```
This simplifies the logic and will be more forwards
compatible with other extended datatypes.

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

This moves the legalization of G_FMA to the action builder that can handle more
types. The existing arm64-vfloatintrinsics.ll has been removed as they are
covered in other test files.

…macros

As per review comments on https://reviews.llvm.org/D150226, we should
allow for one more release before turning this warning into a hard
error, by making it visible in system headers and macros, so that people
are aware of it and can work on it.

The 'counted_by' attribute is used on flexible array members. The
argument for the attribute is the name of the field member in the same
structure holding the count of elements in the flexible array. This
information can be used to improve the results of the array bound
sanitizer and the '__builtin_dynamic_object_size' builtin.

This example specifies the that the flexible array member 'array' has
the number of elements allocated for it in 'count':

  struct bar;
  struct foo {
    size_t count;
     /* ... */
    struct bar *array[] __attribute__((counted_by(count)));
  };

This establishes a relationship between 'array' and 'count',
specifically that 'p->array' must have *at least* 'p->count' number of
elements available. It's the user's responsibility to ensure that this
relationship is maintained through changes to the structure.

In the following, the allocated array erroneously has fewer elements
than what's specified by 'p->count'. This would result in an
out-of-bounds access not not being detected:

  struct foo *p;

  void foo_alloc(size_t count) {
    p = malloc(MAX(sizeof(struct foo),
                   offsetof(struct foo, array[0]) + count *
                       sizeof(struct bar *)));
    p->count = count + 42;
  }

The next example updates 'p->count', breaking the relationship
requirement that 'p->array' must have at least 'p->count' number of
elements available:

  struct foo *p;

  void foo_alloc(size_t count) {
    p = malloc(MAX(sizeof(struct foo),
                   offsetof(struct foo, array[0]) + count *
                       sizeof(struct bar *)));
    p->count = count + 42;
  }

  void use_foo(int index) {
    p->count += 42;
    p->array[index] = 0; /* The sanitizer cannot properly check this access */
  }

Reviewed By: nickdesaulniers, aaron.ballman

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

[mlir][Linalg]: Optimize linalg generic in transform::PromoteOp to avoid unnecessary copies (#68555)

If the operands are not used in the payload of linalg generic operations, there is no need to copy them before the operation.

This patch adds a `SBType::FindDirectNestedType(name)` function which performs a non-recursive search in given class for a type with specified name. The intent is to perform a fast search in debug info, so that it can be used in formatters, and let them remain responsive.

This is driven by my work on formatters for Clang and LLVM types. In particular, by [`PointerIntPairInfo::MaskAndShiftConstants`](https://github.com/llvm/llvm-project/blob/cde9f9df79805a0850310870d6dcc64004292727/llvm/include/llvm/ADT/PointerIntPair.h#L174C16-L174C16), which is required to extract pointer and integer from `PointerIntPair`.

Related Discourse thread: https://discourse.llvm.org/t/traversing-member-types-of-a-type/72452

Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class. This patch replaces
{big,little,native} with llvm::endianness::{big,little,native}.

This patch completes the migration to llvm::endianness and
llvm::endianness::{big,little,native}.  I'll post a separate patch to
remove the migration helpers in llvm/Support/Endian.h:

  using endianness = llvm::endianness;
  constexpr llvm::endianness big = llvm::endianness::big;
  constexpr llvm::endianness little = llvm::endianness::little;
  constexpr llvm::endianness native = llvm::endianness::native;

hasOneUse can be more expensive for nodes with multiple outputs.
It's better to check the opcode first to skip nodes with multiple
outputs.

I have not seen an issue from this, just noticed while reviewing
code for a possible enhancement.

These source files do not use StringMap.h.

These source files do not use StringMap.h.

These source files do not use function_ref.

Update `LegalizerHelper::widenScalarMulo` to not create a mulo if we aren't going to use the overflow flag. This prevents needing to legalize the widened operation. This generates better code when we need to make a libcall for multiply.

These source files do not use StringMap.

Identified with misc-unused-using-decls.

`R_PPC64_GOT_TLSGD_PCREL34` is generated for pwr10+.

The last use of StringMap was removed by:

  commit 20157410
  Author: Vince Bridgers <vince.a.bridgers@gmail.com>
  Date:   Thu Jul 16 12:55:32 2020 -0500

This PR addresses a smaller detail discussed in the code review for
https://github.com/llvm/llvm-project/pull/66968. Currently, some
functions in the `libc++` PSTL CPU backend have been appended with a
digit to indicate the number of input iterator arguments. However, there
is no need to change the name for each version as overloading can be
used instead. This PR will make the naming more consistent in the the
CPU and the proposed OpenMP backend.