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

Given the style:
```
BraceWrapping
  AfterFunction: true
 SplitEmptyFunction: true
 SplitEmptyRecord: false
...
```

The code that should be like:
```
void f(int aaaaaaaaaaaaaaaaaaaaaaaaaaaa,
       int bbbbbbbbbbbbbbbbbbbbbbbb)
{
}
```

gets the braces merged together:
```
void f(int aaaaaaaaaaaaaaaaaaaaaaaaaaaa,
       int bbbbbbbbbbbbbbbbbbbbbbbb)
{}
```

Reviewed By: MyDeveloperDay

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

Creating threads after a multi-threaded fork is semi-supported,
we don't give particular guarantees, but we try to not fail
on simple cases and we have die_after_fork=0 flag that enables
not dying on creation of threads after a multi-threaded fork.
This flag is used in the wild:
https://github.com/mongodb/mongo/blob/23c052e3e321dbab90f1863d4d5539d7c1a1cf44/SConstruct#L3599

fork_multithreaded.cpp test started hanging in debug mode
after the recent "tsan: fix deadlock during race reporting" commit,
which added proactive ThreadRegistryLock check in SlotLock.

But the test broke earlier after "tsan: remove quadratic behavior in pthread_join"
commit which made tracking of alive threads based on pthread_t stricter
(CHECK-fail on 2 threads with the same pthread_t, or joining a non-existent thread).
When we start a thread after a multi-threaded fork, the new pthread_t
can actually match one of existing values (for threads that don't exist anymore).
Thread creation sta...

To allow transition from the TS-specified
std::experimental::coroutine_traits to the C++20-specified
std::coroutine_traits, we lookup in both places and provide helpful
diagnostics. This refactors the code to avoid separate paths to
std::experimental lookups.

Reviewed By: ChuanqiXu

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

The VPWidenCanonicalIVRecipe must always be created in the phi section
of the header block. Use that block as insert point.

Add test for various customization point object properties as defined by
the Standard. Test various CPOs from `<ranges>`, `<iterator>`,
`<concepts>`, etc.

The test is mostly from https://reviews.llvm.org/D107036 and split up
into this.

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

This fixes a typo/bug when checking for pointer reuse when testing
DI location preservation in the Debugify original mode (when
checking -g generated Debug Info).

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

Thanks to @zturner for the initial patch!

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

Improve the readability of these if(Style==FormatStyle::LK_JavsScript) clauses

https://github.com/llvm/llvm-project/issues/49846

Fixes #49846

AlignConsecutiveDeclarations  is not working for "let" and "const" in JavaScript

let letVariable     = 5;
const constVariable = 10;

Reviewed By: owenpan, HazardyKnusperkeks, curdeius

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

Add an overload that accepts and returns an Address, as we
generally just want to replace the pointer with a laundered one,
while retaining remaining information.

This consistently completes the renaming started in D115986.

* There is no reason to forbid that case
* Also, user will get very unfriendly error like `expected result type with offset = -9223372036854775808 instead of 1`

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

Move shift-by-constant handling and move it into its only user (VSHIFT intrinsics lowering).

This is some prep-work for getTargetVShiftNode to no longer take a scalar shift amount - we're introducing temporary ISD::EXTRACT_VECTOR_ELT nodes via SelectionDAG::getSplatValue to accommodate this which can cause various issues, including unnecessary scalarization and xmm->gpr->xmm transfers, and causes problems for 32-bit codegen if we fail to remove an (illegal) i64 scalar extracted from a (legal) vXi64 vector.

This avoids some pointer element type accesses when compiling
C++ code.

Allow `__move_constexpr` to work with unrelated pointers and `_LIBCPP_ASSERT` that `__copy_constexpr`, `__move_constexpr` and `__assign_constexpr` are only run during constant evaluation

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

Some buildbots still rely on the experimental flag, so let's keep
it until everything has been migrated to the new "on by default"
state.

If we miss both close of a file descriptor and a subsequent open
if the same file descriptor number, we report false positives
between operations on the old and on the new descriptors.

There are lots of ways to create new file descriptors, but for closing
there is mostly close call. So we try to handle at least it.
However, if the close happens in an ignored library, we miss it
and start reporting false positives.

Handle closing of file descriptors always, even in ignored libraries
(as we do for malloc/free and other critical functions).
But don't imitate memory accesses on close for ignored libraries.

FdClose checks validity of the fd (fd >= 0) itself,
so remove the excessive checks in the callers.

Reviewed By: melver

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

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

Pull out the "rotl(x,y) --> (unpack(x,x) << zext(splat(y % bw))) >> bw" special case from vXi8 lowering so we can reuse it for vXi32 types as well.

There's still some regressions with vXi16 to handle before this becomes entirely general.

It also allows us to remove the now unnecessary hack for handling amount-modulo before splatting.

This doesn't generate any nodes so should be usable by methods with const SelectionDAG &.

Rename option MaxConstantsThreshold to MaxClonesThreshold. Not only is this
more descriptive, this is also in preparation of introducing another threshold
to analyse more than just 1 constant argument as we currently do, and to better
distinguish these options/thresholds.

Script (llvm-mca-compare.py) uses llvm-mca tool to print
statistics in console for multiple files.
Script requires specified --llvm-mca-binary option (specified
relative path to binary of llvm-mca).
Options: --args [="-option1=<arg> -option2=<arg> ..."], -v or -h can also be used.

The script is used as follows:
$ llvm-project/llvm/utils/llvm-mca-compare.py file1.s --llvm-mca-binary=build/bin/llvm-mca

Patch by Milica Matic <Milica.Matic@syrmia.com>

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

Using comparisons instead avoids potential overflow.

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

All callers pass in a GlobalVariable, so we can conveniently fetch
the type from there.

Attempt to lower a shuffle as a permute instruction(zip/uzp/trn) for fixed length SVE.

Reviewed By: paulwalker-arm

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

Depends on D113980.

Reviewed By: melver

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

We used to use u64 as mutex id because it was some
tricky identifier built from address and reuse count.
Now it's just the mutex index in the report (0, 1, 2...),
so use int to represent it.

Depends on D112603.

Reviewed By: melver

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

Revert "[NFC] [C++20] [Modules] Add tests for template instantiation in transitively imported module"

This reverts commit 4f103e95.

The tests couldn't pass under windows.

These callbacks are used for SSE vector accesses.
In some computational programs these accesses dominate.
Currently we do 2 uninlined 8-byte accesses to handle them.
Inline and optimize them similarly to unaligned accesses.
This reduces the vector access benchmark time from 8 to 3 seconds.

Depends on D112603.

Reviewed By: melver

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

This commit adds two test about template class instantiation in
transitively imported module. They are used as pre-commit tests for
successive patches.

sec->repl equals sec after rL371216.

Depends on D115940 for the `Binary_rv_vr_vv` pattern class op isel
fragment used for divisions.

Reviewed By: kaz7

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

This fixes the assertion failure reported at
https://reviews.llvm.org/D114889#3198921 with a straightforward
check, until the cleaner fix in D115924 can be reapplied.

Loads always have an alignment now, so this is no longer relevant.