When an include from a textual header is resolved, the textual header's
submodule is used as the requesting module. The submodule's uses are
resolved, but that doesn't work because only top level modules have
uses, and only the top level module uses are used for checking uses in
Module::directlyUses. ModuleMap::resolveUses to resolve the top level
module instead of the submodule.

Summary:
We should not rely on a VLA in C++ for the handling of this string. The
size is a true runtime value so we cannot rely on constexpr handling. We
simply use a small vector, whose default size is most likely large
enough to handle whatever size gets output within the stack, but is safe
in cases where it is not.

The entry point symbol handling matches our GCC link spec..
```%{!shared:%{!nostdlib:%{!r:%{!e*:-e __start}}}}```

Remove usage of -Bdynamic as it is the default for the linker anyway.

Came up in discussion here https://github.com/llvm/llvm-project/pull/65644

So we can differentiate on the while keyword between a do-while-loop and
a normal while-loop.

- only return when the return type is non-void
- fix missing return on member functions

Correcting a small typo in the error message when the CUDA device libraries are not detected.

The implicit conversion from an op to a Value is not triggered for some reasons:

/LoopLikeSCFOpsTest.cpp:78:57: error: call of overloaded ‘ValueRange(mlir::arith::ConstantIndexOp)’ is ambiguous
       b.create<scf::ParallelOp>(loc, ValueRange(lb.get()), ValueRange(ub.get()),

explicitly taking the result of the op should solve it.

The llvm.exp.* family of intrinsics and their corresponding libcalls
were recently added, which means we need to know their signatures.

This just reorganizes the code to make it clear what the existing cases were
doing in common.  An upcoming change will extend the logic.

Legalizer, register bank selection, and instruction selection.

Remove bad test for >2x XLen scalar. Don't restrict struct returns if they aren't homogenous.

Original commit message:
Types larger than 2*XLen are passed indirectly which is not supported
yet. Currently, we will incorrectly pass X10 multiple times.

We currently shrink the type of vmv_s_x_vl to LMUL=1 when its passthru
is
undef to avoid constraining the register allocator since it ignores
LMUL.
This patch relaxes it for non-undef passthrus, which occurs when
lowering
insert_vector_elt.

This reverts commit 3a4b0e93.

Seems to be failing on the build bots.

This handles the case where this combine:
icmp sgt (ashr X, ShAmtC), C --> icmp sgt X, ((C + 1) << ShAmtC) - 1

wasn't performed by instcombine.

Proof of the original combine: https://alive2.llvm.org/ce/z/SfpsvX

This is a port of the review in https://reviews.llvm.org/D151911 to
GitHub.

Types larger than 2*XLen are passed indirectly which is not supported
yet. Currently, we will incorrectly pass X10 multiple times.

This reverts commit c80b5034.

This change causes a fatal error in the backend and is filed as issue #69670.

This commit adjusts the CUDA context management in the SerializeToCubin
pass. In particular, it uses the device 0 primary context instead of
creating a new CUDA context on each invocation of SerializeToCubin. This
yields very large improvements in compile time, especially if an
application (like a JIT compiler) is calling SerializeToCubin
repeatedly.

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



Co-authored-by: Rohan Yadav <rohany@cs.stanford.edu>

Issue: https://github.com/llvm/llvm-project/issues/69270

These atomic primitives are required in order to implement the race
variants of the new And and Or operators in Go's sync/atomic package.
See Github issue golang/go#61395.

This caused linker issues on a buildbot:
https://lab.llvm.org/buildbot/#/builders/61/builds/50716.

This reverts commit 3c07a216.

MSVC has a major performance regression observed when targeting ARM64
since v19.32 (VS 17.2.0). `cl.exe` spends a lot of time on compiling
`StandardLibrary.cpp` and `CGBuiltin.cpp`, and total build duration
rises extremely. This makes builds stagnate even on a real hardware, but
VM-based builds (like building on cloud agents from GitHub Actions and
Azure Pipelines) are experiencing most damage as they also performance-
and time-limited.

The issue appears to be related to some optimizations applied in `/O2`
mode. It is reported on [Developer
Community](https://developercommunity.visualstudio.com/t/Compiling-a-specific-code-for-ARM64-with/10444970).
While the investigation is in progress, we could apply a workaround to
improve build time. `/O2` actually enables a set of optimizations, and
only one of them does all slowdown. The idea is to disable
optimizations, and then apply all but one back, effectively excluding
the problematic option from the set.

This patch alters the CMake configuration for aforementioned files.
Changes are limited to:
- non-debug builds
- MSVC of the specific version
- target arch (ARM64).

This was reverted in commit 0abaf3ca
(#67178).

This version of the patch includes a fix which was caused by
vp-reductions having an extra start value argument which the non-vp
counterparts did not have.

Reapplication of 7339c0f7 with a fix
for a crash involving arrays without a size expression.

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they're expressed in C have been considered by WG21
and rejected, are easy to use accidentally to the surprise of users
(e.g., https://ddanilov.me/default-non-standard-features/), and they
have potential security implications beyond constant-size arrays
(https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range).
C++ users should strongly consider using other functionality such as
std::vector instead.

This seems like sufficiently compelling evidence to warn users about
VLA use by default in C++ modes. This patch enables the -Wvla-extension
diagnostic group in C++ language modes by default, and adds the warning
group to -Wall in GNU++ language modes. The warning is still opt-in in
C language modes, where support for VLAs is somewhat less surprising to
users.

RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109
Fixes https://github.com/llvm/llvm-project/issues/62836
Differential Revision: https://reviews.llvm.org/D156565

This PR adds options to let CMake calculate the ninja job pools
depending on free memory and available cores.
You can provide memory requirements for each compile and link job which
is checked against CMake AVAILABLE_PHYSICAL_MEMORY and
NUMBER_OF_LOGICAL_CORES. [This information are available since CMake
3.0](https://cmake.org/cmake/help/v3.0/command/cmake_host_system_information.html).

This is very helpful in CI environments with multiple jobs per
environment or a VM with multiple users.
Its different to LLVM_PARALLEL_LINK_JOBS / LLVM_PARALLEL_COMPILE_JOBS
(or ninja -j 1) because it tries to use the resources more efficient
without being terminated. Only downside currently is that compile and
link jobs can run at the same time so there is an offset for link job
memory suggested which is added to the documentation.

The definitions aren't added as cache because if I understand it
correctly this would break it because values could be outdated.

"--sysroot"
should be 
"--sysroot="

since it's related to
OPT_sysroot_EQ
and not a
OPT_sysroot

[Clang][OpenMP] Check if value is contained in array, not if it's contained in the first element (#69462)

This change adds the PLATFORM XMACRO to simplify the addition of new MachO
platforms and reduce the number of required changes. Many of the changes needed
for adding a new platform are mechanical, such as adding new cases to a switch
statement. This will help streamline the process by consolidating much of the
necessary information into the MachO.def file.

This prevents redefinition errors due to having multiple paths for the
same module map. (rdar://24116019)

Originally implemented and tested downstream by @bcardosolopes, I just
made use of `FileEntryRef::getNameAsRequested()`.

This reverts commit ed83797f.

Reverting pending the investigation of https://github.com/llvm/llvm-project/issues/69658

This reverts commit e6e90840.

This is to fix https://github.com/llvm/llvm-project/issues/69697.

Shift the `determinant()` function from LinearTransform to Matrix.
Implement a FracMatrix class, inheriting from Matrix<Fraction>, for inverses.
Implement inverse for FracMatrix and intInverse for IntMatrix.
Make Matrix internals protected instead of private so that Int/FracMatrix can access them.

Without this patch, the functions `executeScriptInternal` and thus
`runOnce` in `llvm/utils/lit/lit/TestRunner.py` return either a tuple like
`(out, err, exitCode, timeoutInfo)` or a `lit.Test.Result` object. They
return the latter only when there's a lit internal shell parse error in
a RUN line. In my opinion, a more straight-forward way to handle
exceptional cases like that is to use python exceptions.

For that purpose, this patch introduces `ScriptFatal`. Thus, this patch
changes `executeScriptInternal` to always either return the tuple or
raise the `ScriptFatal` exception. It updates `runOnce` and
`libcxx/utils/libcxx/test/format.py` to catch the exception rather than
check for the special return type.

This patch also changes `runOnce` to convert the exception to a
`Test.UNRESOLVED` result instead of `TEST.FAIL`. The former is the
proper result for such a malformed test, for which a rerun (given an
`ALLOW_RETRIES:`)...

On RISC-V, GNU as produces the following initial instruction in CIE's:

```
DW_CFA_def_cfa_register: r2
```

While I believe it is technically illegal to use this instruction
without first using a `DW_CFA_def_cfa` (since the offset is undefined),
both `readelf` and `llvm-dwarfdump` accept this and implicitly set the
offset to 0.

In BOLT, however, this triggers an assert (in `CFISnapshot::advanceTo`)
as it (correctly) believes the offset is not set. This patch fixes this
by setting the offset to 0 whenever executing `DW_CFA_def_cfa_register`
while the offset is undefined.

Note that this is probably the simplest workaround but it has a
downside: while emitting CFI start, we check if the initial instructions
are contained within `MCAsmInfo::getInitialFrameState` and omit them if
they are. This will not be true for GNU CIE's (since they differ from
LLVM's) which causes an unnecessary `DW_CFA_def_cfa_register` to be
emitted.

While...

Due to an issue when lowering from scf to spirv as there was no
conversion pass for index to spirv, we are motivated to add a conversion
pass from the Index dialect to the SPIR-V dialect. Furthermore, we add
the new conversion patterns to the scf-to-spirv conversion.

Fixes #63713