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.

Following of https://github.com/llvm/llvm-project/pull/86912

The motivation of the patch series is that, for a module interface unit
`X`, when the dependent modules of `X` changes, if the changes is not
relevant with `X`, we hope the BMI of `X` won't change. For the specific
patch, we hope if the changes was about irrelevant declaration changes,
we hope the BMI of `X` won't change. **However**, I found the patch
itself is not very useful in practice, since the adding or removing
declarations, will change the state of identifiers and types in most
cases.

That said, for the most simple example,

```
// partA.cppm
export module m:partA;

// partA.v1.cppm
export module m:partA;
export void a() {}

// partB.cppm
export module m:partB;
export void b() {}

// m.cppm
export module m;
export import :partA;
export import :partB;

// onlyUseB;
export module onlyUseB;
import m;
export inline void onluUseB() {
    b();
}
```

the BMI of `onlyUseB` will change after we change the implementation of
`partA.cppm` to `partA.v1.cppm`. Since `partA.v1.cppm` introduces new
identifiers and types (the function prototype).

So in this patch, we have to write the tests as:

```
// partA.cppm
export module m:partA;
export int getA() { ... }
export int getA2(int) { ... }

// partA.v1.cppm
export module m:partA;
export int getA() { ... }
export int getA(int) { ... }
export int getA2(int) { ... }

// partB.cppm
export module m:partB;
export void b() {}

// m.cppm
export module m;
export import :partA;
export import :partB;

// onlyUseB;
export module onlyUseB;
import m;
export inline void onluUseB() {
    b();
}
```

so that the new introduced declaration `int getA(int)` doesn't introduce
new identifiers and types, then the BMI of `onlyUseB` can keep
unchanged.

While it looks not so great, the patch should be the base of the patch
to erase the transitive change for identifiers and types since I don't
know how can we introduce new types and identifiers without introducing
new declarations. Given how tightly the relationship between
declarations, types and identifiers, I think we can only reach the ideal
state after we made the series for all of the three entties.

The design of the patch is similar to
https://github.com/llvm/llvm-project/pull/86912, which extends the
32-bit DeclID to 64-bit and use the higher bits to store the module file
index and the lower bits to store the Local Decl ID.

A slight difference is that we only use 48 bits to store the new DeclID
since we try to use the higher 16 bits to store the module ID in the
prefix of Decl class. Previously, we use 32 bits to store the module ID
and 32 bits to store the DeclID. I don't want to allocate additional
space so I tried to make the additional space the same as 64 bits. An
potential interesting thing here is about the relationship between the
module ID and the module file index. I feel we can get the module file
index by the module ID. But I didn't prove it or implement it. Since I
want to make the patch itself as small as possible. We can make it in
the future if we want.

Another change in the patch is the new concept Decl Index, which means
the index of the very big array `DeclsLoaded` in ASTReader. Previously,
the index of a loaded declaration is simply the Decl ID minus
PREDEFINED_DECL_NUMs. So there are some places they got used
ambiguously. But this patch tried to split these two concepts.

As https://github.com/llvm/llvm-project/pull/86912 did, the change will
increase the on-disk PCM file sizes. As the declaration ID may be the
most IDs in the PCM file, this can have the biggest impact on the size.
In my experiments, this change will bring 6.6% increase of the on-disk
PCM size. No compile-time performance regression observed. Given the
benefits in the motivation example, I think the cost is worthwhile.

Avoid usage DEFAULT_SYSROOT CMake variable to confgiure the ARM/Aarch64
cross platform toolchain builds. Use the Clang configuration files with
proper `--sysroot=` in it instead.

More details could be found here:
    https://github.com/llvm/llvm-project/issues/94284

To avoid generating unnecessary values, we don't create a new value but
instead
leave it to the specific analysis to do this if desired.

Remove support for the icmp and fcmp constant expressions.

This is part of:
https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179

As usual, many of the updated tests will no longer test what they were
originally intended to -- this is hard to preserve when constant
expressions get removed, and in many cases just impossible as the
existence of a specific kind of constant expression was the cause of the
issue in the first place.

Convert all arith.cmpf on floats (not vectors/tensors thereof) to EmitC.

---------

Co-authored-by: Matthias Gehre <matthias.gehre@amd.com>
Co-authored-by: Jose Lopes <jose.lopes@amd.com>