When merging scales of `LinearExpression` that have common index
variables, we cannot guarantee the NSW flag still applies to the merged
expression.

Fixes #69096.

The corresponding function definition was removed by:

  commit 7e5c2672
  Author: Amara Emerson <amara@apple.com>
  Date:   Mon Sep 25 03:22:25 2023 +0800

The corresponding function definition was removed by:

  commit a6be2671
  Author: Jay Foad <jay.foad@amd.com>
  Date:   Tue Feb 23 16:10:19 2021 +0000

The corresponding function definition was removed by:

  commit 63254466
  Author: Evan Cheng <evan.cheng@apple.com>
  Date:   Wed Mar 5 00:59:57 2008 +0000

This patch adds translation to LLVM IR for `num_teams` and
`thread_limit` in for `omp.teams` operation.

Currently, If the C or C++ compiler supports the `-gsplit-dwarf` option it is added to _all_ compilers.
If a project decides to use another  language, such as Swift, this option will be sent to that compiler as well, regardless whether that compiler supports it or not (Swift doesnot).
This patch uses [generator expressions](https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html) to limit the `-gsplit-dwarf` option to only those compilers that support it (C and C++).

After this patch, the softfp implementations of floatdidf and floatundidf
use a common implementation (int_to_fp.h and int_to_fp_impl.inc). This
roughly follows the pattern used for a wide range of other builtins,
e.g. fp_trunc_impl.inc.

Currently there is substantial copy and paste for the various int to fp
conversion functions, with just a few constants being changed. This is a
barrier to maintainability, and it's also not attractive to copy this
approach as we introduce additional int to fp conversion functions for
bf16 and half (which we currently lack, but need - see
<https://reviews.llvm.org/D157509>).

I've opted to conservatively start by replacing just two functions,
leaving a follow-up patch to replace others that follow the same
pattern. Also, for better or worse I've left the logic in float[un]didf
largely unchanged other than using a similar approach to
fp_trunc_impl.inc to rem...

Resolve #68857.
Alive2 proofs:
[Whole proofs](https://alive2.llvm.org/ce/z/A5b85F)

* Downplay cfe-commits as a place where design discussion happens.
  Instead, call it out as a place for historical information.
* Add a link to Discord
* Add a link to Office Hours

`i64 @labs(i32)` is incorrectly recognized as `LibFunc_labs` because
type ID `Long` matches both `i32` and `i64`. This PR requires the type
of argument to match the return value.

Fixes #69059.

Remove use after free when attempting to update SlotIndexes in
MachineBasicBlock::SplitCriticalEdge.

Use MachineFunction delegate mechanism to capture target specific
manipulations of branch instructions and update SlotIndexes.

My previous commit leads to a failure in 'Builders/ppc64le-lld-multistage-test',
as shown at "https://lab.llvm.org/buildbot/#/builders/36/builds/38790".

Identified with misc-unused-using-decls.

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.