Nothing in the standard actually prevents TARGET from being an
assumed-rank if the POINTER is. The only rank related constraints says:
"POINTER is not assumed-rank, TARGET shall have the same rank as
POINTER.".

This adds compare and branch instructions fusion for Neoverse V2.
According to the Software Optimization Guide:
Specific Aarch64 instruction pairs that can be fused are as follows: 
CMP/CMN (immediate) + B.cond
CMP/CMN (register) + B.cond

Performance for SPEC2017 is neutral, but another benchmark improves
significantly.
Results for SPEC2017 on a Neoverse V2:
500.perlbench 0%
502.gcc_r 0%
505.mcf_r -0.15%
523.xalancbmk_r -0.43%
525.x264_r 0%
531.deepsjeng_r 0%
541.leela_r -0.16%
557.xz_r -0.47%

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

Original commit message:"

[clang-repl] Extend the C support. (#89804)

The IdResolver chain is the main way for C to implement lookup rules.  Every new
partial translation unit caused clang to exit the top-most scope which in turn
cleaned up the IdResolver chain. That was not an issue for C++ because its
lookup is implemented on the level of declaration contexts.

This patch keeps the IdResolver chain across partial translation units
maintaining proper C-style lookup infrastructure.
"

It was reverted in dfdf1c5f because it broke the
bots of lldb. This failure was subtle to debug but the current model does not
work well with ObjectiveC support in lldb. This patch does cleans up the
partial translation units in ObjectiveC. In future if we want to support
ObjectiveC we need to understand what exactly lldb is doing when recovering from
errors...

The range may no longer be valid after the select has been
optimized away.

This fixes the kernel miscompiles reported at
https://github.com/ClangBuiltLinux/linux/issues/2031.

This patch covers the following Core issues:
[CWG1862](https://cplusplus.github.io/CWG/issues/1862.html) "Determining
“corresponding members” for friendship"
[CWG1918](https://cplusplus.github.io/CWG/issues/1918.html) "`friend`
templates with dependent scopes"
[CWG1945](https://cplusplus.github.io/CWG/issues/1945.html) "Friend
declarations naming members of class templates in non-templates"

All of them were resolved by CWG1862, where the current wording of
[[temp.friend] p5](https://eel.is/c++draft/temp.friend#5) comes from:
> A template friend declaration may declare a member of a dependent type
to be a friend[.](https://eel.is/c++draft/temp.friend#5.sentence-1) The
friend declaration shall declare a function or specify a type with an
[elaborated-type-specifier](https://eel.is/c++draft/dcl.type.elab#nt:elaborated-type-specifier),
in either case with a
[nested-name-specifier](https://eel.is/c++draft/expr.prim.id.qual#nt:nested-name-specifier)
ending with a
[simple-template-id](https://eel.is/c++draft/temp.names#nt:simple-template-id),
C, whose
[template-name](https://eel.is/c++draft/temp.names#nt:template-name)
names a class
template[.](https://eel.is/c++draft/temp.friend#5.sentence-2) The
template parameters of the template friend declaration shall be
deducible from C
([[temp.deduct.type]](https://eel.is/c++draft/temp.deduct.type))[.](https://eel.is/c++draft/temp.friend#5.sentence-3)
In this case, a member of a specialization S of the class template is a
friend of the class granting friendship if deduction of the template
parameters of C from S succeeds, and substituting the deduced template
arguments into the friend declaration produces a declaration that
corresponds to the member of the
specialization[.](https://eel.is/c++draft/temp.friend#5.sentence-4)

A useful example is provided after the paragraph:
https://eel.is/c++draft/temp.friend#example-4

.

Neither of Core issues is implemented, because we don't support
dependent nested friend specifiers.

---------

Co-authored-by: Shafik Yaghmour <shafik.yaghmour@intel.com>

When doing a runtimes build with LTO using ld.bfd (or ld.gold), the
build starts failing with ninja 1.12, which added a new critical path
scheduler. The reason is that LLVMgold.so is not available yet at the
point where runtimes start being build, leading to configuration
failures in the nested cmake invocation.

Fix this by adding an explicit dependency on LLVMgold.so if it is
available. (It may not always be necessary, e.g. if the used linker is
lld, but it would be hard to detect when exactly it may or may not be
needed, so always adding the dependency is safer.)

Pass variadic arguments without changing their type, unlike the fixed
ones.

Fixed arguments are modified to better fit into registers. This patch
leaves those unchanged.

Splitting struct types into individual fields and packing small structs
into integers works well for passing via registers. Variadic arguments
are currently unimplemented in the backend. They're likely to be
implemented as a pointer to stack memory in which case register-themed
optimisations are inapplicable.

Splitting the struct into fields makes it difficult to implement va_arg
robustly. The rules around padding and alignment to inverse the struct
splitting could be constructed, but at high complexity and no particular
advantage.

Passing types as-is means there is a 1:1 correspondence with the type
information va_arg has to work with and the parameter type at the call
site.

This is an ABI change, but as the only functions affected are variadic
ones which are presently a compilation error, not a functional break.
Factored out of the larger #93362 and can land independently.

Add overloads of GetElementPtrInst::Create() that accept
GEPNoWrapFlags, and switch the bool parameters in IRBuilder to
accept it instead as well.

As a sample use, switch GEP i8 canonicalization in InstCombine to
preserve the original flags.

Don't skip searching in `ToContext` during importing `EnumDecl`. And
`IsStructuralMatch` in `StructralEquivalence` can make sure to determine
whether the found result is match or not.

---------

Co-authored-by: huqizhi <836744285@qq.com>

Currently an expression is inlined without emitting enclosing
parentheses regardless of the context of the user. This could led to
wrong evaluation order depending on the precedence of both expressions.
If the inlining is intended, the user operation should be merged into
the expression op.

Fixes #93470.

Store getSE result in variable to re-use and use structured bindings
when looping over bounds.

This came up when testing the CI build, which is not
being build with scripting yet.

The DISubrange can take integer, dwarf expressions or variables. The
current translation only handled integers. This PR adds handling of
dwarf expressions and variables.

This patch refactors an existing test for
[CWG2390](https://cplusplus.github.io/CWG/issues/2390.html) "Is the
argument of `__has_cpp_attribute` macro-expanded?" to use `#error`
instead of emitting a variable in IRGen and checking it via FileCheck.
As a bonus, this makes it possible to move the test into `cwg23xx.cpp`.

The pass constructor can be generated automatically by tablegen.

The pass is module-level and iterates over every operation within the
module so it should not need any changes to support alternative top
level operations.

This preserves the flags if a constexpr GEP is created (at least
as long as they don't get dropped later -- the test cases uses a
constexpr index to avoid that).

Motivated by the review process in
https://github.com/llvm/llvm-project/pull/75912. This can also help to
simplify the code slightly.

Add a test case with a missed simplification when hoisting runtime
checks due to not applying loop guards.

This preserves the flags during that transform, but currently they
will still end up getting dropped at a later stage.

Flags are already fully preserved for the instruction case,
but lost on constant expressions.

This reverts commit d8ec452d.

This fails on LLDB macOS CI. See
https://github.com/llvm/llvm-project/pull/92083 for details.

Checker alpha.security.PutenvStackArray is moved to
security.PutenvStackArray.

VPTypeAnalysis::inferScalarTypeForRecipe is missing the case for
VPInstruction::LogicalAnd, due to which the test
vplan-incomplete-cases.ll crashes. Add this missing case, and move the
test in vplan-infer-not-or-type.ll to vplan-incomplete-cases.ll, showing
correct codegen for trip-counts 2 and 3.

Since the switch to opaque pointers, zero-index GEPs will be
optimized away anyway, so there is no need to explicitly handle
them here.

Fix regression introduced by #93216

Fixes #93650

Inspired by the review process in
https://github.com/llvm/llvm-project/pull/92085.

The check `ID >= FirstIdentID` can cover the following check
`!II->isFromAST()`.

Update the folder titles for targets in the monorepository that have not
seen taken care of for some time. These are the folders that targets are
organized in Visual Studio and XCode
(`set_property(TARGET <target> PROPERTY FOLDER "<title>")`)
when using the respective CMake's IDE generator.

 * Ensure that every target is in a folder
 * Use a folder hierarchy with each LLVM subproject as a top-level folder
 * Use consistent folder names between subprojects
 * When using target-creating functions from AddLLVM.cmake, automatically
deduce the folder. This reduces the number of
`set_property`/`set_target_property`, but are still necessary when
`add_custom_target`, `add_executable`, `add_library`, etc. are used. A
LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's
root CMakeLists.txt.