move constructors should be marked noexcept

If the loop bound is not initialized, the analysis crashed, as it only checked for nullity. Also checking for initialization fixes the issue.

Signed-off-by: Victor Perez <victor.perez@codeplay.com>
Co-authored-by: Tsang, Whitney <whitney.tsang@intel.com>

This is used for eliminate uses of "CurDAG", which is SelectionDAG-spec,
and not compatible with GIsel algorithms.

(NFC)

This patch tries to reduce the size of the BMIs by packing more bits
into an unsigned integer.

This patch was reverted due to buildbot failure report. But it should be
irrevelent after I took a double look. So I tried to recommit this NFC
change again.

Added the following functions for manipulating operand bundles, as well as
building ``call`` and ``invoke`` instructions that use operand bundles:

  * LLVMBuildCallWithOperandBundles
  * LLVMBuildInvokeWithOperandBundles
  * LLVMCreateOperandBundle
  * LLVMDisposeOperandBundle
  * LLVMGetNumOperandBundles
  * LLVMGetOperandBundleAtIndex
  * LLVMGetNumOperandBundleArgs
  * LLVMGetOperandBundleArgAtIndex
  * LLVMGetOperandBundleTag

Fixes #71873.

As part of #73798 there was some discussion about using the format
helper to run from a git-hook. That was not possible for a number of
reasons, but with these changes it can now be installed as a hook and
then run on the local cache in git instead of a diff between revisions.

This also checks for two environment variables DARKER_FORMAT_PATH and
CLANG_FORMAT_PATH where you can specify the path to the program you want
to use.

Support loops without static boundaries. Since the number of iteration
is not known we need to predicate prologue and epilogue in case the
number of iterations is smaller than the number of stages.

This patch includes work from @chengjunlu

This reverts commit 10951050.
This should be part of 8c334627 to revert
9406ea3f completely.

This reverts commit 9406ea3f.

There are build bots complaining this. Revert it first to try to keep
the bots green.

Forgot to rename `winehprepare` for legacy pass when port this pass to
new passmanager.

The member functions of ScheduleDAGMI are called back from
PostMachineScheduler::runOnMachineFunction, instead of
MachineScheduler::runOnMachineFunction.

Replaced explicit loops with find + erase.

llvm-project/clang/lib/Serialization/ASTWriterDecl.cpp:2342:12:
 error: unused variable 'ExprDependenceBits' [-Werror,-Wunused-variable]
 2342 |   unsigned ExprDependenceBits = llvm::BitWidth<ExprDependence>;
      |            ^~~~~~~~~~~~~~~~~~
1 error generated.

If a local stub is out-of-range, at LongJmp we will try to find another
local stub first. However, The original implementation do not work as
expected and it leads to an infinite loop between replaceTargetWithStub
and fixBranches.

After this patch, we first convert the target of BB back to the target
of the local stub, and then look up for other valid local stubs and so
on.

This is similar to single and double-precision floating-point
instructions.

This patch tries to reduce the size of the BMIs by packing more bits
into an unsigned integer.

Akin other passes - refactored the name to `InstrProfilingLoweringPass` to better communicate what it does, and split the pass part and the transformation part to avoid needing to initialize object state during `::run`.

A subsequent PR will move `InstrLowering` to the .cpp file and rename it to `InstrLowerer`.

Forgot to update the counterpart in `CodeGenPassBuilder.h`. Also Rename `dwarfehprepare` -> `dwarf-eh-prepare`.

Found while running libc++'s tests with MSVC's STL.

*
`libcxx/test/std/algorithms/alg.sorting/alg.heap.operations/sort.heap/ranges_sort_heap.pass.cpp`
+ Fix Clang `-Wunused-variable`, because `LIBCPP_ASSERT` expands to
nothing for MSVC's STL.
+ This is the same "always void-cast" change that #73437 applied to the
neighboring `complexity.pass.cpp`. I missed that
`ranges_sort_heap.pass.cpp` was also affected because we had disabled
this test.
*
`libcxx/test/std/input.output/file.streams/fstreams/ifstream.members/buffered_reads.pass.cpp`
*
`libcxx/test/std/input.output/file.streams/fstreams/ofstream.members/buffered_writes.pass.cpp`
+ Fix MSVC "warning C4244: '`=`': conversion from '`__int64`' to
'`_Ty`', possible loss of data".
+ This is a valid warning, possibly the best one that MSVC found in this
entire saga. We're accumulating a `std::vector<std::streamsize>` and
storing the result in `std::streamsize total_size` but we actually have
to start with `std::streamsize{0}` or we'll truncate.
*
`libcxx/test/std/input.output/filesystems/fs.enum/enum.path.format.pass.cpp`
+ Fix Clang `-Wunused-local-typedef` because the following usage is
libc++-only.
+ I'm just expanding it at the point of use, and using the dedicated
`LIBCPP_STATIC_ASSERT` to keep the line length down.
*
`libcxx/test/std/input.output/syncstream/syncbuf/syncstream.syncbuf.assign/swap.pass.cpp`
+ Fix MSVC "warning C4242: 'argument': conversion from '`int`' to
'`const _Elem`', possible loss of data".
+ This is a valid warning (possibly the second-best) as `sputc()`
returns `int_type`. If `sputc()` returns something unexpected, we want
to know, so we should separately say `expected.push_back(CharT('B'))`.
*
`libcxx/test/std/language.support/support.dynamic/new.delete/new.delete.single/new.size_align_nothrow.pass.cpp`
*
`libcxx/test/std/language.support/support.dynamic/new.delete/new.delete.single/new.size_nothrow.pass.cpp`
  + Fix MSVC "warning C6001: Using uninitialized memory '`x`'."
  + [N4964](https://wg21.link/N4964) \[new.delete.single\]/12:
> *Effects:* The deallocation functions
(\[basic.stc.dynamic.deallocation\]) called by a *delete-expression*
(\[expr.delete\]) to render the value of `ptr` invalid.
  + \[basic.stc.general\]/4:
> When the end of the duration of a region of storage is reached, the
values of all pointers representing the address of any part of that
region of storage become invalid pointer values (\[basic.compound\]).
Indirection through an invalid pointer value and passing an invalid
pointer value to a deallocation function have undefined behavior. Any
other use of an invalid pointer value has implementation-defined
behavior.
+ In certain configurations, after `delete x;` MSVC will consider `x` to
be radioactive (and in other configurations, it'll physically null out
`x` as a safety measure). We can copy it into `old_x` before deletion,
which the implementation finds acceptable.
*
`libcxx/test/std/ranges/range.adaptors/range.elements/general.pass.cpp`
*
`libcxx/test/std/ranges/range.adaptors/range.elements/iterator/deref.pass.cpp`
+ Fix MSVC "warning C4242: 'initializing': conversion from '`_Ty`' to
'`_Ty`', possible loss of data".
+ This was being emitted in `pair` and `tuple`'s perfect forwarding
constructors. Passing `short{1}` allows MSVC to see that no truncation
is happening.
*
`libcxx/test/std/ranges/range.adaptors/range.elements/iterator/member_types.compile.pass.cpp`
+ Fix MSVC "warning C4242: 'initializing': conversion from '`_Ty`' to
'`_Ty2`', possible loss of data".
+ Similarly, this was being emitted in `pair`'s perfect forwarding
constructor. After passing `short{1}`, I reduced repetition by relying
on CTAD. (I can undo that cleanup if it's stylistically undesirable.)
*
`libcxx/test/std/utilities/function.objects/refwrap/refwrap.const/type_conv_ctor.pass.cpp`
+ Fix MSVC "warning C4930: '`std::reference_wrapper<int> purr(void)`':
prototyped function not called (was a variable definition intended?)".
+ There's no reason for `purr()` to be locally declared (aside from
isolating it to a narrow scope, which has minimal benefits); it can be
declared like `meow()` above. 😸
*
`libcxx/test/std/utilities/memory/util.smartptr/util.smartptr.shared/util.smartptr.shared.create/make_shared_for_overwrite.pass.cpp`
*
`libcxx/test/std/utilities/smartptr/unique.ptr/unique.ptr.create/make_unique_for_overwrite.default_init.pass.cpp`
  + Fix MSVC static analysis warnings when replacing `operator new`:
    ```
warning C28196: The requirement that '(_Param_(1)>0)?(return!=0):(1)' is
not satisfied. (The expression does not evaluate to true.)
warning C6387: 'return' could be '0': this does not adhere to the
specification for the function 'new'.
warning C6011: Dereferencing NULL pointer 'reinterpret_cast<char
*>ptr+i'.
    ```
+ All we need is a null check, which appears in other `operator new`
replacements:
https://github.com/llvm/llvm-project/blob/b85f1f9b182234ba366d78ae2174a149e44d08c1/libcxx/test/std/language.support/support.dynamic/new.delete/new.delete.single/new.size.replace.pass.cpp#L27-L28

Found while running libc++'s tests with MSVC's STL.

*
`libcxx/test/std/algorithms/alg.modifying.operations/alg.unique/ranges_unique_copy.pass.cpp`
  + Fix MSVC "warning C4389: '`==`': signed/unsigned mismatch".
+ This was x86-specific for me. The LHS is `int` and the RHS is
`size_t`. We know the `array`'s size, so `static_cast<int>` is certainly
safe, and this matches the following `numberOfProj` comparisons.
*
`libcxx/test/std/containers/sequences/insert_range_sequence_containers.h`
+ Fix MSVC "warning C4267: 'argument': conversion from '`size_t`' to
'`const int`', possible loss of data".
+ `test_case.index` is `size_t`:
https://github.com/llvm/llvm-project/blob/b85f1f9b182234ba366d78ae2174a149e44d08c1/libcxx/test/std/containers/insert_range_helpers.h#L65-L68
+ But the container's `difference_type` is `int`:
https://github.com/llvm/llvm-project/blob/b85f1f9b182234ba366d78ae2174a149e44d08c1/libcxx/test/support/test_allocator.h#L65-L76
  + I introduced an alias `D` to make the long line more readable.
*
`libcxx/test/std/containers/unord/unord.map/eq.different_hash.pass.cpp`
*
`libcxx/test/std/containers/unord/unord.multimap/eq.different_hash.pass.cpp`
*
`libcxx/test/std/containers/unord/unord.multiset/eq.different_hash.pass.cpp`
*
`libcxx/test/std/containers/unord/unord.set/eq.different_hash.pass.cpp`
+ Fix MSVC "warning C6297: Arithmetic overflow. Results might not be an
expected value."
+ This warning is almost annoying enough to outright disable, but we use
similar `static_cast`s to deal with sign/truncation warnings elsewhere,
because there's some value in ensuring that product code is clean with
respect to these warnings. If there were many more occurrences, then
disabling the warning would be appropriate.
+ Cleanup: Change 2 inconsistently unqualified occurrences of `size_t`
to `std::size_t`.
*
`libcxx/test/std/containers/views/mdspan/layout_stride/index_operator.pass.cpp`
+ Fix MSVC "warning C4244: 'initializing': conversion from '`__int64`'
to '`size_t`', possible loss of data".
+ This was x86-specific for me. The `args` are indeed `int64_t`, and
we're storing the result in `size_t`, so we should cast.
* `libcxx/test/std/ranges/range.utility/range.utility.conv/container.h`
+ Fix MSVC "warning C4244: 'initializing': conversion from '`ptrdiff_t`'
to '`int`', possible loss of data".
+ Fix MSVC "warning C4267: 'initializing': conversion from '`size_t`' to
'`int`', possible loss of data".
+ We're initializing `int size_`, so we should explicitly cast from
pointer subtraction and `std::ranges::size`.
*
`libcxx/test/std/utilities/memory/util.smartptr/util.smartptr.shared/util.smartptr.shared.create/allocate_shared_for_overwrite.pass.cpp`
*
`libcxx/test/std/utilities/memory/util.smartptr/util.smartptr.shared/util.smartptr.shared.create/make_shared_for_overwrite.pass.cpp`
*
`libcxx/test/std/utilities/smartptr/unique.ptr/unique.ptr.create/make_unique_for_overwrite.default_init.pass.cpp`
+ Fix MSVC "warning C4309: 'initializing': truncation of constant
value".
+ MSVC emits this warning because `0xDE` is outside the range of `char`
(signed by default in our implementation).
* `libcxx/test/support/concat_macros.h`
+ Fix MSVC "warning C4244: 'argument': conversion from '`char16_t`' to
'`const char`', possible loss of data".
+ Fix MSVC "warning C4244: 'argument': conversion from '`unsigned int`'
to '`const char`', possible loss of data".
  + This code was very recently introduced by @mordante in #73395.

https://github.com/ARM-software/abi-aa/pull/227 changes IDs of
`R_AARCH64_AUTH_ABS64` and `R_AARCH64_AUTH_RELATIVE` in PAuth ABI
specification from draft ones (`0xe100` and `0xe200`) to final ones
(`0x244` and `0x411`).

This patch changes the values in llvm correspondingly.

Follow up to
https://github.com/llvm/llvm-project/pull/73698#discussion_r1411134482

Comments use `##`. Lit and FileCheck directives should use single `#`.
See
https://github.com/llvm/llvm-project/pull/72713#discussion_r1398788122.

A small typographical fix in `CoverageMappingFormat.rst`.

This is a syntax cleanup, not needed for running libc++'s tests with
MSVC's STL.

While changing
`libcxx/test/std/input.output/filesystems/fs.enum/enum.path.format.pass.cpp`
in #74965, I noticed that libc++'s tests almost always use the
special-purpose macros for "this is a libc++-specific `static_assert`
etc." defined by:

https://github.com/llvm/llvm-project/blob/b85f1f9b182234ba366d78ae2174a149e44d08c1/libcxx/test/support/test_macros.h#L240-L253

However, there were a very small number of occurrences that were using
the general-purpose `LIBCPP_ONLY` macro when they could have been using
the special-purpose macros. I believe that they should be cleaned up, to
make it easier to search for usage, and to make it clearer when the full
power of `LIBCPP_ONLY` is necessary.

This is a pure regex replacement from
`LIBCPP_ONLY\((assert|static_assert|ASSERT_NOEXCEPT|ASSERT_NOT_NOEXCEPT)\((.*)\)\);`
to `LIBCPP_\U$1($2);` using the power of [VSCode's case changing in
regex
replace](https://code.visualstudio.com/docs/editor/codebasics#_case-changing-in-regex-replace).

To avoid merge conflicts, this isn't changing the line in
`libcxx/test/std/input.output/filesystems/fs.enum/enum.path.format.pass.cpp`
that #74965 is already changing to use `LIBCPP_STATIC_ASSERT`.

Found while running libc++'s test suite with MSVC's STL.

* In `escaped_output.unicode.pass.cpp`, replace `_LIBCPP_SHORT_WCHAR`
with `TEST_SHORT_WCHAR`.
+ This was the only test that was directly using the `_LIBCPP` macro.
`libcxx/test/support/test_macros.h` performs this mapping:
https://github.com/llvm/llvm-project/blob/c60ac509399da5cba533b9b6cc5b983c59f7d7b3/libcxx/test/support/test_macros.h#L442-L444
* In `msvc_stdlib_force_include.h`, define `TEST_SHORT_WCHAR`.

@mordante This was introduced by #73395 a couple of days ago.

This is causing PR checks to fail, [stage3 (generic-no-wide-characters,
libcxx-runners-8-set,
OFF)](https://github.com/llvm/llvm-project/actions/runs/7154839054/job/19484723909?pr=74254#logs):

```
In file included from /home/runner/_work/llvm-project/llvm-project/libcxx/test/std/utilities/format/format.tuple/format.functions.vformat.pass.cpp:29:
/home/runner/_work/llvm-project/llvm-project/libcxx/test/support/concat_macros.h:86:1: error: expected ')'
   86 | OutIt test_transcode(InIt first, InIt last, OutIt out_it) {
      | ^
/home/runner/_work/llvm-project/llvm-project/libcxx/test/support/concat_macros.h:80:11: note: to match this '('
   80 |   requires(std::output_iterator<OutIt, const char&> &&
      |           ^
/home/runner/_work/llvm-project/llvm-project/libcxx/test/std/utilities/format/format.tuple/format.functions.vformat.pass.cpp:63:2: error: expected unqualified-id
   63 | }
      |  ^
```

Add test cases with varying distances between stores and loads that may
prevent store-to-load forwarding.

Found while running libc++'s test suite with MSVC's STL.

After @CaseyCarter's [LLVM-D118279](https://reviews.llvm.org/D118279)
https://github.com/llvm/llvm-project/commit/c5ba46ea1804dfefb22e6d2bb65ff1636d2cc8cd
"\[libcxx\]\[test\] `MaybePOCCAAllocator` should meet the
*Cpp17Allocator* requirements" followed by @philnik777's
[LLVM-D68365](https://reviews.llvm.org/D68365)
https://github.com/llvm/llvm-project/commit/98d3d5b5da66e3cf7807c23a0294280bb796466b
"\[libc++\] Implement [P1004R2](https://wg21.link/P1004R2) (`constexpr
std::vector`)", one more change is necessary.

MSVC's `constexpr vector` implementation noticed this because we always
rebind allocators.

 I accidentally closed
https://github.com/llvm/llvm-project/pull/74806

If the dynamic allocation size is 0, then we will still probe the
current sp value despite not decrementing sp! This results in
overwriting stack data, in my case the stack canary.

The fix here is just to load the value of [sp] into xzr which is
essentially a no-op but still performs a read/probe of the new page.