Aggressive inlining might produce huge functions with >10K of basic 
blocks. Since BFI treats _all_ blocks and jumps as "hot" having 
non-negative (but perhaps small) weight, the current implementation can
be slow, taking minutes to produce an layout. This change introduces a
few modifications that significantly (up to 50x on some instances) 
speeds up the computation. Some notable changes:
- reduced the maximum chain size to 512 (from the prior 4096);
- introduced MaxMergeDensityRatio param to avoid merging chains with
very different densities;
- dropped a couple of params that seem unnecessary.

Looking at some "offline" metrics (e.g., the number of created 
fall-throughs), there shouldn't be problems; in fact, I do see some
metrics go up. But it might be hard/impossible to measure perf 
difference for such small changes. I did test the performance clang-14 
binary and do not record a perf or i-cache-related differences.

My 5 benchmarks, with ext-tsp runtime (the lower the better) and 
"tsp-score" (the higher the better).
**Before**:

- benchmark 1:
  num functions: 13,047
  reordering running time is 2.4 seconds
  score: 125503458 (128.3102%)
- benchmark 2:
  num functions: 16,438
  reordering running time is 3.4 seconds
  score: 12613997277 (129.7495%)
- benchmark 3:
  num functions: 12,359
  reordering running time is 1.9 seconds
  score: 1315881613 (105.8991%)
- benchmark 4:
  num functions: 96,588
  reordering running time is 7.3 seconds
  score: 89513906284 (100.3413%)
- benchmark 5:
  num functions: 1
  reordering running time is 372 seconds
  score: 21292505965077 (99.9979%)
- benchmark 6:
  num functions:  71,155
  reordering running time is 314 seconds
  score: 29795381626270671437824 (102.7519%)

**After**:
- benchmark 1:
  reordering running time is 2.2 seconds
  score: 125510418 (128.3130%)

- benchmark 2:
  reordering running time is 2.6 seconds
  score: 12614502162 (129.7525%)

- benchmark 3:
  reordering running time is 1.6 seconds
  score: 1315938168 (105.9024%)

- benchmark 4:
  reordering running time is 4.9 seconds
  score: 89518095837 (100.3454%)

- benchmark 5:
  reordering running time is 4.8 seconds
  score: 21292295939119 (99.9971%)

- benchmark 6:
  reordering running time is 104 seconds
  score: 29796710925310302879744 (102.7565%)

Summary:
The `llvm_omp_target_dynamic_shared_alloc` prototype in `omp.h`
accidentally left the void argument unspecified. This created unintended
code when called from the C language, causing some `nvlink` failures in
certain scenarios.

After PR#69417, lowering for combined constructs was updated to adhere
to OpenACC 3.3, section 2.11: `A private or reduction clause on a
combined construct is treated as if it appeared on the loop construct.`

However, the second part of that paragraph notes `In addition, a
reduction clause on a combined construct implies a copy clause`. Since
the acc dialect decomposes combined constructs, it is important to
distinguish between the case where an explicit data clause is required
(as noted in section 2.6.2) and the case where an implicit data action
must be generated by compiler.

Replace these intrinsics with the corresponding GISel operators during
legalization stage to reuse available selection patterns.

This allows querying whether, given the flow condition, a certain
formula still
has a solution (though it is not necessarily implied by the flow
condition, as
`flowConditionImplies()` would check).

This can be checked today, but only with a double negation, i.e. to
check
whether, given the flow condition, a formula F has a solution, you can
check
`!Env.flowConditionImplies(Arena.makeNot(F))`. The double negation makes
this
hard to reason about, and it would be nicer to have a way of directly
checking
this.

For consistency, this patch also renames `flowConditionImplies()` to
`proves()`;
the old name is kept around for compatibility but deprecated.

Methods StreamChecker::preFread and StreamChecker::preFwrite are quite
similar, so they can be combined to StreamChecker::preFreadFwrite.

[NFC][Clang] Make read-only arguments of GetSDLFromOffloadArchive and SDLSearch read-only references instead of copying them

[X86] combineArithReduction - use PACKUSWB directly for PSADBW(TRUNCATE(v8i16 X)) reduction patterns

Avoids a crash in the D152928 patch due to a reduction pattern appearing after legalization

We can probably extend this further to avoid truncating to sub-128-bit vXi8 (and then calling WidenToV16I8) entirely, but we can't currently hit other cases.

This reverts commit 3ab03ad3.

Reverted due to failing expensive-checks buildbots, e.g.
https://lab.llvm.org/buildbot/#/builders/16/builds/56317. Will
investigate that.

This is used in #69148 when lowering masked tile_store with non-zero
pad, see #69148

This updates:
 * `arm_sme.move_vector_to_tile_slice`
 * `arm_sme.move_tile_slice_to_vector`

Refactor `uintptr_t` inside of `clang::Selector` that holds a pointer to `IdentifierInfo` or `MultiKeywordSelector` and `IdentifierInfoFlag` enum into `PointerIntPair`. This is a part of `PointerIntPair` migration outlined in https://github.com/llvm/llvm-project/issues/69835.

Unlike `uintpt_t`, `PointerIntPair` required pointee types to be complete, so I had to shuffle definitions of `MultiKeywordSelector` and `detail::DeclarationNameExtra` around to make them complete at `Selector`. Also, there were outdated specializations of `PointerLikeTypeTraits` for `IdentifierInfo *`, which are no longer needed, because `alignof` that primary template use works just fine. Not just that, but they declared that `IdentifierInfo *` has only 1 spare lower bit, but today they are 8-byte aligned.

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

Make GetSDLFromOffloadArchive and SDLSearch functions static since they
are used only in the file where they are defined. The aim is to ease
refactoring/modifying the declarations of these functions in the future.

Summary:
This patch is a first step to remove dependencies on the OpenMPIRBuilder
for creating generic offloading entries. This patch changes no
functionality and merely moves the code around. In the future the
interface will be changed to allow for more code re-use in the
registration and creation of offloading entries as well as a more
generic interface for CUDA, HIP, OpenMP, and SYCL(?). Doing this as a
first step to reduce the noise involved in the functional changes.

This output has now changed because I moved the za register
into the main SME register set.

Some fixes for style issues pointed out by clang-tidy:

- Upper case/lower case fixes
- No else after return
- Removed unused #include's
- Added NOLINTNEXTLINE() for the LLVM* functions

All changes are NFC.

Also update the release notes.

Even though we're only interested in the X64 codegen for the first test, its much easier to maintain if we just let the update script generate the codegen checks for X86 as well.

The HWEncoding values currently form a strange mix of actual register
codes for some subtargets and types of operands and informational flags.
This patch removes the dependency allowing arbitrary changes in the
structure of HWEncoding values without breaking register encodings.

Such changes, in turn, would make it possible to speed up and simplify
getAVOperandEncoding() testing for AGPRs as well as other functions
dealing with register codes downstream. They would also allow to
maintain the same format of HWEncoding values across our downstream code
bases, thus simplifying merging in mainline changes.

clang-format brace wrapping did not take requires into consideration,
compound requirements will be affected by BraceWrapping.AfterFunction.

Closes #59412.

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

When implementing thread_local as a keyword in C23, we accidentally
started using C++11 thread_local semantics when using that keyword
instead of using C11 _Thread_local semantics.

This oversight is fixed by pretending the user wrote _Thread_local
instead. This doesn't have the best behavior in terms of diagnostics,
but it does correct the semantic behavior.

Fixes https://github.com/llvm/llvm-project/issues/70068
Fixes https://github.com/llvm/llvm-project/issues/69167

Back when the --icf= option was hooked up in the MinGW frontend in LLD,
in 2017, lld-link didn't support safe ICF, and mapping it to noicf was
suggested in review: https://reviews.llvm.org/D40019

In 2018, in ab038025,
lld-link did get support for handling address significance tables,
allowing the ICF to operate safely on more sections.

Later in 2021, lld-link did get support for a separate safe ICF mode in
5bdc5e7e /
https://reviews.llvm.org/D97436.

Hook this up for the MinGW frontend as well.

In msan mode this calls __msan_unpoison, which isn't constexpr.

TSan can show only line numbers on some platforms, e.g., SystemZ. Skip
checking the column numbers; line numbers should be enough to verify
that race detection is working.

Teach SelectionDAG::salvageDebugInfo() to salvage debug information for
ADD nodes where the RHS is non-constant.
    
Co-authored-by: Mikael Holmen <mikael.holmen@ericsson.com>

- [DebugInfo] Precommit testcase for pointer addition with unknown
offset
- [SelectionDAG] Salvage debug info for non-constant ADDs

---------

Co-authored-by: Mikael Holmen <mikael.holmen@ericsson.com>

We now stop aligning trailing comments on all closing braces, for
classes etc. we even check for the semicolon between the comment and the
brace.
    
Fixes #67906.

These turn out to be useful for spec2017/fotonik3d and safe so long as
they are not used along side TBAA tags for local allocations. LLVM may
be able to figure out local allocations by itself anyway.

PR #68727

So we only have to read cpuinfo once.

This reverts commit ef336594.

It was causing incorrect codegen for some Vulkan CTS tests.

There is a report about a large compile time regression in V8 when
generating debug info.

Currently, the SLS hardening pass is run before the machine outliner,
which means that the outliner creates new functions and calls which do
not have the SLS hardening applied.

The fix for this is to move the SLS passes to after the outliner, as has
recently been done for the return address signing pass.

This also avoids a bug where the SLS outliner emits code with
instructions after a return, which the outliner doesn't correctly
handle.

Reviewed By: kristof.beyls

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

The current verifier stopped verification with a success value as soon
as a type was encountered that cannot be indexed into. The correct
behaviour in this case is to error out as there are too many indices for
the element type. Not doing so leads to bad user-experience as an
invalid GEP is likely to fail only later during LLVM IR translation.

This PR implements the correct verification behaviour. Some tests
upstream had to also be fixed as they were creating invalid GEPs.

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

Do not emit call to llvm.dbg.declare when the variable declaration
is a DecompositionDecl as its instance class is always unnamed.

The emitted debug declare looks like:

call void @llvm.dbg.declare(metadata ..., metadata !xx, metadata ...)
!xx = !DILocalVariable(scope: !..., file: !..., line: ..., type: !...)