Implement `llvm.coro.await.suspend` intrinsics, to deal with performance
regression after prohibiting `.await_suspend` inlining, as suggested in
#64945.
Actually, there are three new intrinsics, which directly correspond to
each of three forms of `await_suspend`:
```
void llvm.coro.await.suspend.void(ptr %awaiter, ptr %frame, ptr @wrapperFunction)
i1 llvm.coro.await.suspend.bool(ptr %awaiter, ptr %frame, ptr @wrapperFunction)
ptr llvm.coro.await.suspend.handle(ptr %awaiter, ptr %frame, ptr @wrapperFunction)
```
There are three different versions instead of one, because in `bool`
case it's result is used for resuming via a branch, and in
`coroutine_handle` case exceptions from `await_suspend` are handled in
the coroutine, and exceptions from the subsequent `.resume()` are
propagated to the caller.

Await-suspend block is simplified down to intrinsic calls only, for
example for symmetric transfer:
```
%id = call token @llvm.coro.save(ptr null)
%handle = call ptr @llvm.coro.await.suspend.handle(ptr %awaiter, ptr %frame, ptr @wrapperFunction)
call void @llvm.coro.resume(%handle)
%result = call i8 @llvm.coro.suspend(token %id, i1 false)
switch i8 %result, ...
```
All await-suspend logic is moved out into a wrapper function, generated
for each suspension point.
The signature of the function is `<type> wrapperFunction(ptr %awaiter,
ptr %frame)` where `<type>` is one of `void` `i1` or `ptr`, depending on
the return type of `await_suspend`.
Intrinsic calls are lowered during `CoroSplit` pass, right after the
split.

Because I'm new to LLVM, I'm not sure if the helper function generation,
calls to them and lowering are implemented in the right way, especially
with regard to various metadata and attributes, i. e. for TBAA. All
things that seemed questionable are marked with `FIXME` comments.

There is another detail: in case of symmetric transfer raw pointer to
the frame of coroutine, that should be resumed, is returned from the
helper function and a direct call to `@llvm.coro.resume` is generated.
C++ standard demands, that `.resume()` method is evaluated. Not sure how
important is this, because code has been generated in the same way
before, sans helper function.

The `MSB` must not be greater than `GRLen`. Without this patch, newly
added test cases will crash with LoongArch32, resulting in a 'cannot
select' error.

Proofs: https://alive2.llvm.org/ce/z/oSRGBt

Closes #84691

[InstCombine] Tests for `(icmp eq/ne (and (shl -1, X), Y), 0)` -> `(icmp eq/ne (lshr Y, X), 0)`; NFC

This allows handling importlibs produced by llvm-dlltool in #78772.
ARM64EC import libraries use it by default, but it's supported by MSVC
link.exe on other platforms too.

This also avoids assuming null-terminated input, like in #78769.

Implement `msync` as specified in:

1. https://www.man7.org/linux/man-pages/man2/msync.2.html
2. https://pubs.opengroup.org/onlinepubs/9699919799/

Summary:
This is a NFC move preceding more radical functional changes to the
allocator implementation. We just move it to a common utility so it will
be easier to write these in tandem.

Currently ObjCStubsSection is handling both the logic for the
"__objc_stubs" section, as well as the logic for the "__objc_selrefs"
section.
While this is OK for now, it will be an issue for other features that
want to interact with the "__objc_selrefs" section, such as upcoming
relative method lists feature - which will also want to create /
reference entries in the "__objc_selrefs" section.
In this PR we split the logic relating to handling the "__objc_selrefs"
section into a new SyntheticSection (ObjCSelRefsSection). Non-functional
change - neither the behavior nor implementation changes, the interface
is just made more friendly to not have "__objc_selrefs" so bound to
"__objc_stubs".

---------

Co-authored-by: Alex B <alexborcan@meta.com>

`(icmp eq/ne (and X, ~Mask), 0)` is equivilent to `(icmp eq/ne (and X,
Mask), X` and we sometimes generate the former pattern intentionally
to reduce number of uses of `X`.
Proof: https://alive2.llvm.org/ce/z/3u-usC

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

Closes #81562

Make recursive matcher that is able to detect a lot more patterns.
Proofs for all supported patterns: https://alive2.llvm.org/ce/z/fSQ3nZ

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

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

Summary:
This header isn't strictly necessary, and is currently broken because we
install these to separate locations.

After #84657 was merged,
[buildbot](https://lab.llvm.org/buildbot/#/builders/250/builds/19808) is
reporting two errors for libc-x86_64-debian-gcc-fullbuild-dbg. This PR
addresses the truncation error for `CPP::bit_ceil<unsigned char>` and
`CPP::bit_ceil<unsigned short>`.

The errors are:

```
FAILED: projects/libc/src/stdbit/CMakeFiles/libc.src.stdbit.stdc_bit_ceil_uc.dir/stdc_bit_ceil_uc.cpp.o
/usr/bin/g++ -DLIBC_NAMESPACE=__llvm_libc_19_0_0_git -D_DEBUG -I/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/build/projects/libc/src/stdbit -I/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/stdbit -I/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc -isystem /home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/build/projects/libc/include -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -fno-lifetime-dse -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-nonnull -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-vir!
 tual-dtor
  -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -g -fpie -ffreestanding -fno-builtin -fno-exceptions -fno-lax-vector-conversions -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-rtti -ftrivial-auto-var-init=pattern -Wall -Wextra -Werror -Wconversion -Wno-sign-conversion -Wimplicit-fallthrough -Wwrite-strings -Wextra-semi -DLIBC_COPT_PUBLIC_PACKAGING -std=c++17 -MD -MT projects/libc/src/stdbit/CMakeFiles/libc.src.stdbit.stdc_bit_ceil_uc.dir/stdc_bit_ceil_uc.cpp.o -MF projects/libc/src/stdbit/CMakeFiles/libc.src.stdbit.stdc_bit_ceil_uc.dir/stdc_bit_ceil_uc.cpp.o.d -o projects/libc/src/stdbit/CMakeFiles/libc.src.stdbit.stdc_bit_ceil_uc.dir/stdc_bit_ceil_uc.cpp.o -c /home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/stdbit/stdc_bit_ceil_uc.cpp
In file included from /home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/stdbit/stdc_bit_ceil_uc.cpp:11:
/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/__support/CPP/bit.h: In instantiation of ‘constexpr __llvm_libc_19_0_0_git::cpp::enable_if_t<is_unsigned_v<T>, T> __llvm_libc_19_0_0_git::cpp::bit_ceil(T) [with T = unsigned char; enable_if_t<is_unsigned_v<T>, T> = unsigned char]’:
/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/stdbit/stdc_bit_ceil_uc.cpp:17:23:   required from here
/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/__support/CPP/bit.h:196:57: error: conversion from ‘unsigned int’ to ‘unsigned char’ may change value [-Werror=conversion]
  196 |   return static_cast<T>(T(1) << cpp::bit_width<T>(value - 1u));
      |                                                   ~~~~~~^~~~
cc1plus: all warnings being treated as errors
[138/466] Building CXX object projects/libc/src/stdbit/CMakeFiles/libc.src.stdbit.stdc_bit_ceil_us.dir/stdc_bit_ceil_us.cpp.o
FAILED: projects/libc/src/stdbit/CMakeFiles/libc.src.stdbit.stdc_bit_ceil_us.dir/stdc_bit_ceil_us.cpp.o
/usr/bin/g++ -DLIBC_NAMESPACE=__llvm_libc_19_0_0_git -D_DEBUG -I/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/build/projects/libc/src/stdbit -I/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/stdbit -I/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc -isystem /home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/build/projects/libc/include -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -fno-lifetime-dse -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-nonnull -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-vir!
 tual-dtor
  -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -g -fpie -ffreestanding -fno-builtin -fno-exceptions -fno-lax-vector-conversions -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-rtti -ftrivial-auto-var-init=pattern -Wall -Wextra -Werror -Wconversion -Wno-sign-conversion -Wimplicit-fallthrough -Wwrite-strings -Wextra-semi -DLIBC_COPT_PUBLIC_PACKAGING -std=c++17 -MD -MT projects/libc/src/stdbit/CMakeFiles/libc.src.stdbit.stdc_bit_ceil_us.dir/stdc_bit_ceil_us.cpp.o -MF projects/libc/src/stdbit/CMakeFiles/libc.src.stdbit.stdc_bit_ceil_us.dir/stdc_bit_ceil_us.cpp.o.d -o projects/libc/src/stdbit/CMakeFiles/libc.src.stdbit.stdc_bit_ceil_us.dir/stdc_bit_ceil_us.cpp.o -c /home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/stdbit/stdc_bit_ceil_us.cpp
In file included from /home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/stdbit/stdc_bit_ceil_us.cpp:11:
/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/__support/CPP/bit.h: In instantiation of ‘constexpr __llvm_libc_19_0_0_git::cpp::enable_if_t<is_unsigned_v<T>, T> __llvm_libc_19_0_0_git::cpp::bit_ceil(T) [with T = short unsigned int; enable_if_t<is_unsigned_v<T>, T> = short unsigned int]’:
/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/stdbit/stdc_bit_ceil_us.cpp:17:23:   required from here
/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/__support/CPP/bit.h:196:57: error: conversion from ‘unsigned int’ to ‘short unsigned int’ may change value [-Werror=conversion]
  196 |   return static_cast<T>(T(1) << cpp::bit_width<T>(value - 1u));
      |                                                   ~~~~~~^~~~
cc1plus: all warnings being treated as errors
```

Closes #84652.

Based on #84233.

Fixes #84660

Summary:
Cleans up two warnings I get locally while building.

MLIROpenACCTransforms does not use the LLVMIR dialect yet includes
LLVMIR headers. This causes building MLIROpenACCTransforms only from a
clean build to fail with:
In file included from
mlir/lib/Dialect/OpenACC/Transforms/LegalizeData.cpp:9:
In file included from
mlir/include/mlir/Dialect/OpenACC/Transforms/Passes.h:12:
mlir/include/mlir/Dialect/LLVMIR/Transforms/AddComdats.h:21:10: fatal
error: 'mlir/Dialect/LLVMIR/Transforms/Passes.h.inc' file not found

This patch removes the problematic includes.

Found that this failed with an assertion when vec was used in this
optimization while working on https://github.com/llvm/llvm-project/pull/84627.

Fixes #84658.

Assuming these were typos in the first place.

I am unsure of the best way to ensure that both sides of the
preprocessor condition in
`libc/include/llvm-libc-macros/stdbit-macros.h` are tested. Could
someone point me in the right direction for adding test coverage to the
non `__cplusplus` branch? Or maybe it is being tested and I've missed
it.

[utils/TableGen/X86CompressEVEXTablesEmitter.cpp] Make sure the tablegen output for the `checkPredicate` function is deterministic (#84533)

The output for the `checkPredicate` function was depending on a
`std::map` iteration that was non-deterministic from run to run, because
the keys were pointer values.
    
Make a change so that the keys are `StringRef`s so the ordering is
stable.

The previous code would truncate IntegerAPs wider than 64 bits.

This commit adds two new notifications to `RewriterBase::Listener`:
* `notifyPatternBegin`: Called when a pattern application begins during
a greedy pattern rewrite or dialect conversion.
* `notifyPatternEnd`: Called when a pattern application finishes during
a greedy pattern rewrite or dialect conversion.

The listener infrastructure already provides a `notifyMatchFailure`
callback that notifies about the reason for a pattern match failure. The
two new notifications provide additional information about pattern
applications.

This change is in preparation of improving the handle update mechanism
in the `apply_conversion_patterns` transform op.

Until now, `transform.apply_conversion_patterns` consumed the target
handle and potentially invalidated handles. This commit adds tracking
functionality similar to `transform.apply_patterns`, such that handles
are no longer invalidated, but updated based on op replacements
performed by the dialect conversion.

This new functionality is hidden behind a `preserve_handles` attribute
for now.

See issue #84654.

Catches nothing, reported #84654.

This reverts commit 6f7ebcb7.

We were mentioning the creator of the issue with the comment rather than
the creator of the comment.

Fixes #82580

This test uses the MSVC/clang-cl specific -EHsc flag.

This test was recently added, in
ea12c1fa.

MSVC does not define __BYTE_ORDER__ making the check for BigEndian
erroneously evaluate to true and breaking the struct definitions in MSVC
compiled builds correspondingly. The fix adds an additional check for
whether __BYTE_ORDER__ is defined by the compiler to fix these.

---------

Co-authored-by: Vadim Paretsky <b-vadipa@microsoft.com>

To resolve the following issue in the CI build:
```
*** Checking for trailing whitespace left in Clang source files ***
+ grep -rnI '[[:blank:]]$' clang/lib clang/include clang/docs
clang/docs/ReleaseNotes.rst:412:- PTX is no longer included by default when compiling for CUDA. Using
+ echo '*** Trailing whitespace has been found in Clang source files as described above ***'
*** Trailing whitespace has been found in Clang source files as described above ***
+ exit 1
```

This patch fixes the issues introduced in
https://github.com/llvm/llvm-project/commit/bb5c3899d1936ebdf7ebf5ca4347ee2e057bee7f

.

I moved the check for the instruction to be div before I check for the
fast math flags which resolves the crash in

```
float a, b;
double sqrt();
void c() { b = a / sqrt(a); }
```

---------

Co-authored-by: Matt Arsenault <arsenm2@gmail.com>

Adds support for xros when compiling builtins. This is disabled by
default and controlled with COMPILER_RT_ENABLE_XROS, similar to
watchOS/tvOS.

Instead of taking the sign of the cast operation as the required since
for the transform, only force a sign if an operation is maybe
negative.

This gives us more flexability when checking if the floats are safely
converable to integers.

Closes #84389

The current selection is done in the test scripts which gives the user
no control where to find clang-tidy. The version selection itself is
hard-coded and not based on the version of clang used.

This moves the selection to configuration time and tries to find a
better match.
- Mixing the version of clang-tidy and the clang libraries causes ODR
violations. This results in practice in crashes or incorrect results.
- Mixing the version of clang-tidy and the clang binary sometimes causes
issues with supported diagnostic flags. For example, flags tested
against clang 17 may not be available in clang-tidy 16.

Currently clang-tidy 18.1 can be used, it tests against the clang
libraries version 18. This is caused by the new LLVM version numbering
scheme.

The new selection tries to match the clang version or the version of the
HEAD and the last 3 releases. (During the release period libc++ supports
4 versions instead of the typical 3 versions.)

Matches (V)CMPPS/D and makes it easier to algorithmically recreate the instruction name in various analysis scripts I'm working on