#56628 changed the behavior of `-Wmissing-field-initializers`, which
introduces many new warnings in C++ code that uses partial designated
initializers. If such code is being built with `-Wextra -Werror`, this
change will break the build.

This PR adds a new flag that allows to disable these new warnings and
keep the old ones, as was suggested by @AaronBallman in the original
issue:
https://github.com/llvm/llvm-project/issues/56628#issuecomment-1761510850

Fixes  #68933

This patch seeks to create a process that happens on module finalization
for OpenMP, in which a list of operations that had declare target
directives applied to them and were not generated at the time of
processing the original declare target directive are re-checked to apply
the appropriate declare target semantics.

This works by maintaining a vector of declare target related data inside
of the FIR converter, in this case the symbol and the two relevant
unsigned integers representing the enumerators. This vector is added to
via a new function called from Bridge.cpp, insertDeferredDeclareTargets,
which happens prior to the processing of the directive (similarly to
getDeclareTargetFunctionDevice currently for requires), it effectively
checks if the Operation the declare target directive is applied to
currently exists, if it doesn't it appends to the vector. This is a
seperate function to the processing of the declare target via the
overloaded genOMP as we unfortunately do not have access to the list
without passing it through every call, as the AbstractConverter we pass
will not allow access to it (I've seen no other cases of casting it to a
FirConverter, so I opted to not do that).

The list is then processed at the end of the module in the
finalizeOpenMPLowering function in Bridge by calling a new function
markDelayedDeclareTargetFunctions which marks the latently generated
operations. In certain cases, some still will not be generated, e.g. if
an interface is defined, marked as declare target, but has no definition
or usage in the module then it will not be emitted to the module, so due
to these cases we must silently ignore when an operation has not been
found via it's symbol.

The main use-case for this (although, I imagine there is others) is for
processing interfaces that have been declared in a module with a declare
target directive but do not have their implementation defined in the
same module. For example, inside of a seperate C++ module that will be
linked in. In cases where the interface is called inside of a target
region it'll be marked as used on device appropriately (although,
realistically a user should explicitly mark it to match the
corresponding definition), however, in cases where it's used in a
non-clear manner through something like a function pointer passed to an
external call we require this explicit marking, which this patch adds
support for (currently will cause the compiler to crash).

This patch also adds documentation on the declare target process and 
mechanisms within the compiler currently.

Shows 2 major issues:
 - SSE should be free as it splits everything to 128-bit
 - Negative costs for 128 -> 512 concat shuffles

NFC.

These templates are made to match the ergonomics of std::numeric_limits.
Because our style for constexpr variables is ALL_CAPS, we must silence the
linter for these manually.

Link:
https://clang.llvm.org/extra/clang-tidy/#suppressing-undesired-diagnostics

Fixes:

    libc/src/string/memory_utils/utils.h:345:13: warning: invalid case style
    for member 'offset_' [readability-identifier-naming]

Having a trailing underscore for members is a google3 style, not LLVM style.
Removing the underscore is insufficient, as we would then have 2 members with
the same identifier which is not allowed (it is a compile time error). Remove
the getter, and just access the renamed member that's now made public.

Found via:

    $ ninja -k2000 libc-lint 2>&1 | grep readability-identifier-naming

Auto fixed via:

    $ clang-tidy -p build/compile_commands.json \
      -checks="-*,readability-identifier-naming" \
      <filename> --fix

This doesn't fix all instances, just the obvious simple cases where it makes
sense to change the identifier names.  Subsequent PRs will fix up the
stragglers.

This will give us insight into what users are renaming in practice - for
instance, try to gauge the impact of the ObjC rename support.

Fixes #82646

It's common to delete some instructions after using SCEVExpander,
while it is still live (but will not be used afterwards). In that
case, the AssertingVH may trigger. Replace it with a PoisoningVH
so that we only detect the case where the SCEVExpander actually is
used in a problematic fashion after the instruction removal.

The alternative would be to add clear() calls to more code paths.

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

As part of the RemoveDIs project we need LLVM to insert instructions using
iterators wherever possible, so that the iterators can carry a bit of
debug-info. This commit implements some of that by updating the contents of
llvm/lib/Transforms/Utils to always use iterator-versions of instruction
constructors.

There are two general flavours of update:
 * Almost all call-sites just call getIterator on an instruction
 * Several make use of an existing iterator (scenarios where the code is
   actually significant for debug-info)
The underlying logic is that any call to getFirstInsertionPt or similar
APIs that identify the start of a block need to have that iterator passed
directly to the insertion function, without being converted to a bare
Instruction pointer along the way.

Noteworthy changes:
 * FindInsertedValue now takes an optional iterator rather than an
   instruction pointer, as we need to always insert with iterators,
 * I've added a few iterator-taking versions of some value-tracking and
   DomTree methods -- they just unwrap the iterator. These are purely
   convenience methods to avoid extra syntax in some passes.
 * A few calls to getNextNode become std::next instead (to keep in the
   theme of using iterators for positions),
 * SeparateConstOffsetFromGEP has it's insertion-position field changed.
   Noteworthy because it's not a purely localised spelling change.

All this should be NFC.

Arithmetic constants for vector types can be constructed from objects
implementing Python buffer protocol such as `array.array`. Note that
until Python 3.12, there is no typing support for buffer protocol
implementers, so the annotations use array explicitly.

This allows users who include `llvm-project` as a subrepository to
access the `LLVM_VERSION_MAJOR` variable on par with if they were
relying on an installed LLVM and `FindLLVM.cmake`. They just need to do
something like:

```
  get_directory_property(LLVM_VERSION_MAJOR DIRECTORY "third_party/llvm-project/llvm" LLVM_VERSION_MAJOR)
```

Context: https://github.com/openxla/iree/pull/16606 -- like other
projects with similar needs that I found by some googling, our
work-around had been to rely on the CMake cached variable
`CLANG_EXECUTABLE_VERSION`. Being cached, it over time inevitably ended
up having a wrong value.

Added support for runtime strides.

Reviewers: preames, RKSimon

Reviewed By: preames

Pull Request: https://github.com/llvm/llvm-project/pull/81517

This is a follow up of #83004, which made the same change for
`MLIR_CUDA_CONVERSIONS_ENABLED`. As the previous PR, this PR commit
exposes mentioned CMake variable through `mlir-config.h` and uses the
macro that is introduced with the same name. This replaces the macro
`MLIR_ROCM_CONVERSIONS_ENABLED`, which the CMake files previously
defined manually.

… AAPCS frame chain fix (#82801)"

This reverts commit 00e4a419. This patch
was found to cause miscompilations and compilation failures.

https://github.com/llvm/llvm-project/blob/762f762504967efbe159db5c737154b989afc9bb/llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp#L394-L407

Comment from @topperc:
> This transforms assumes the mask is a non-zero splat. We only know its
a splat and not provably all 0s. The mask is a constexpr that includes
the address of the global variable. We can't resolve the constant
expression to an exact value.

Fixes #83947.

Buildbot failure:
https://lab.llvm.org/buildbot/#/builders/5/builds/41530/steps/9/logs/stdio

The promote alloca to vector transformation assumes that the
vector index is a constant value. If it is not a constant, then
either an assert occurs or the tranformation generates an
incorrect index.

Parenthesized list intializers are sequenced operations, see C++20
[decl.init]p16.5 and [decl.init]p16.6.2.2 for more details.

Fixes #83474

In PR #83677 I was surprised to see that outdated checker callback
signatures are a problem. It turns out, we need the `registerChecker...`
function to invoke the `Mgr.registerChecker<>()` which would instantiate
the `_register` calls, that would take the address of the defined
checker callbacks. Consequently, if the expected signatures mismatch, it
won't compile from now on, so we have static guarantee that this issue
never pops up again.

Given we need the `register` call, at this point we could just hook this
checker into the `debug` package and make it never registered. It
shouldn't hurt anyone :)

[Clang][Sema] Fix crash when using name of UnresolvedUsingValueDecl with template arguments (#83842)

The following snippet causes a crash:
```
template<typename T>
struct A : T {
  using T::f;
  void f();

  void g() {
    f<int>(); // crash here
  }
};
```
This happens because we cast the result of `getAsTemplateNameDecl` as a
`TemplateDecl` in `Sema::ClassifyName`, which we cannot do for an
`UnresolvedUsingValueDecl`. This patch fixes the crash by considering a name
to be that of a template if _any_ function declaration is found per [temp.names] p3.3.

Define BUF Real instructions with this general pattern for all
architectures (not just GFX11):

  multiclass Something_Real_gfx11<...> {
    defvar ps = !cast<Pseudo>(NAME);
    def _gfx11 : ...;
  }

This allows removing a huge amount of repetition in the definitions of
individual Real instructions, where they would have to !cast their own
name to a Pseudo and pass that in as a class argument.

When inlining across functions with different target features, we
perform roughly two checks:
 1. The caller features must be a superset of the callee features.
2. Calls in the callee cannot use types where the target features would
change the call ABI (e.g. by changing whether something is passed in a
zmm or two ymm registers). The latter check is very crude right now.

The latter check currently also catches inline asm "calls". I believe
that inline asm should be excluded from this check, as it is independent
from the usual call ABI, and instead governed by the inline asm
constraint string.

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

This patch adds support for canonicalization of icmp with a scalable
splat. Some optimizations assume that `icmp pred X, APInt C` is in
canonical form.

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

Previously SelectionDAGBuilder used ABI alignment for
compressstore/expandload. This patch allows SelectionDAGBuilder to use
parameter alignment like vp intrinsics. This does not follow the
original code to default use vector type alignment, since it is possible
implemented to unaligned vector alignment.

Add functionality to APInt::toString() that allows it to insert
separators between groups of digits, using the C++ literal
separator ' between groups.

Fixes issue #58228

Reviewers:  @AaronBallman, @cjdb, @tbaederr

This allows the removal of FFR related psuedo nodes that only existed to
work round machine verifier failures.

Summary:
The other test locations only give these messages when we are in verbose
logging mode. The average user does not care about which tests are not
being built, and most platforms will have missing tests.

The Base_ prefix seems redundant on a class that is only used for GFX11.

This class only existed to set the dlc bit for GFX11 atomics. It is
simpler to set dlc for all loads/stores/atomics in the base class.

We should generate the `MCInstPredicate` twice, one with `FirstMI`
and another with `SecondMI`.

[InstCombine] Fix Failure to convert vector fp comparisons that can be represented as integers #82241 (#83274)

Resolve #82241

---------

Co-authored-by: SahilPatidar <patidarsahil@2001gmail.com>

According to the PTX ISA this doesn't exist (and ptxas rejects it)

See https://github.com/pytorch/pytorch/issues/118589

I was wondering about this when I recently used `Regex`, and I thought
it would
be nice to have a test documenting this behavior.