Clients of the dependency scanning service may need to add dependencies
based on the visibility of importing modules, for example, when
determining whether a Swift overlay dependency should be brought in
based on whether there's a corresponding **visible** clang module for
it.
This patch introduces a new field `VisibleModules` that contains all the
visible top-level modules in a given TU.
Because visibility is determined by which headers or (sub)modules were
imported, and not top-level module dependencies, the scanner now
performs a separate DFS starting from what was directly imported for
this computation.
In my local performance testing, there was no observable performance
impact.
resolves: rdar://151416358
---------
Co-authored-by: Jan Svoboda <jan@svoboda.ai>
Summary:
The semantics of static libraries only extract stuff that's used. We
somewhat extend this behavior with the linker wrapper only doing this to
fat binaries that match any found architectures. However, this has some
unfortunate effects when the user uses static libraries.
This is somewhat of a hack, but we now assume that if the user specified
`--offload-arch=` on the link job, they *definitely* want that
architecture to be used if it exists. This patch just forces extraction
of those libraries which resolves an issue observed with some customers.
The old behavior will still be present if the user does `--offload-link`
with no offloading architecture present, and for the vast, vast majority
of cases this will change nothing.
Fixes: https://github.com/llvm/llvm-project/issues/147788
This patch fixes an issue where Microsoft-specific layout attributes,
such as __declspec(empty_bases), were ignored during CUDA/HIP device
compilation on a Windows host. This caused a critical memory layout
mismatch between host and device objects, breaking libraries that rely
on these attributes for ABI compatibility.
The fix introduces a centralized hasMicrosoftRecordLayout() check within
the TargetInfo class. This check is aware of the auxiliary (host) target
and is set during TargetInfo::adjust if the host uses a Microsoft ABI.
The empty_bases, layout_version, and msvc::no_unique_address attributes
now use this centralized flag, ensuring device code respects them and
maintains layout consistency with the host.
Fixes: https://github.com/llvm/llvm-project/issues/146047
Add explicit dependency for gen_vt to the CMakeLists.txt for
clang/tools/clang-fuzzer/handle-llvm/handle_llvm.cpp to prevent race
condition on generation of llvm/CodeGen/GenVT.inc This explicit
dependency was added in other CMakeLists.txt when the tablegen was added
for GenVT.inc file in https://reviews.llvm.org/D148770, but not for
handle-llvm
A similar fix was made in
https://github.com/llvm/llvm-project/pull/109306
rdar://151325382
This PR introduces out-of-process (OOP) execution support for
Clang-Repl. With this enhancement, two new flags, oop-executor and
oop-executor-connect, are added to the Clang-Repl interface. These flags
enable the launch of an external executor (llvm-jitlink-executor), which
handles code execution in a separate process.
Introduce a type alias for the commonly used `std::pair<FileID,
unsigned>` to improve code readability, and make it easier for future
updates (64-bit source locations).
[Discourse
link](https://discourse.llvm.org/t/a-small-proposal-for-extraction-of-inline-assembly-block-information/86658)
We strive for exposing such information using existing stable ABIs. In
doing so, queries are limited to what the original source holds or the
LLVM IR `asm` block would expose in connection with attributes that the
queries are concerned.
These APIs opens new opportunities for `rust-bindgen` to translate
inline assemblies in reasonably cases into Rust inline assembly blocks,
which would further aid better interoperability with other existing
code.
---------
Signed-off-by: Xiangfei Ding <dingxiangfei2009@protonmail.ch>
## Problem
When using `-fsave-optimization-record` with offloading, the Clang
driver passes optimization record options like
`-plugin-opt=opt-remarks-format=yaml` to `clang-nvlink-wrapper`.
However, the wrapper doesn't recognize these options, causing
compilation to fail.
## Solution
This patch adds support for the standard optimization record command
line options to `clang-nvlink-wrapper`, matching the interface provided
by LLD and gold-plugin as documented in the [LLVM Remarks
documentation](https://llvm.org/docs/Remarks.html).
## Changes
- **NVLinkOpts.td**: Added definitions for `opt-remarks-filename`,
`opt-remarks-format`, `opt-remarks-filter`, and
`opt-remarks-with-hotness` options
- **NVLinkOpts.td**: Added `plugin-opt=` aliases for these options to
match what the Clang driver sends
- **ClangNVLinkWrapper.cpp**: Updated `createLTO()` to use command line
arguments when available, falling back to existing global variables
## Testing
The fix allows `-fsave-optimization-record` to work correctly with
offloading, generating optimization records during the LTO phase without
throwing unknown argument errors.
This change maintains backward compatibility and follows the existing
pattern used by other LLVM linkers.
While the source code isn't supposed to change during a build, in some
environments it does. This adds an option that disables caching of stat
failures, meaning that source files can be added to the build during
scanning.
This adds a `-no-cache-negative-stats` option to clang-scan-deps to
enable this behavior. There are no tests for clang-scan-deps as there's
no reliable way to do so from it. A unit test has been added that
modifies the filesystem between scans to test it.
Summary:
The logic here is flawed, it was only intended to apply to the CPU case
where we use the linker passed in on the command line. This was falsely
applying to SPIR-V which caused issues.
Fixed two issues:
1. assertion with -flto. the linker wrapper action is missing for
wrapping the device binary. Added it for -flto.
2. when there are two HIP files, the kernels in the second file were not
found. This is because the -r option of linker wrapper assumes offload
entries section of HIP to be hip_offloading_entries but it is actually
llvm_offload_entries, causing the offload entries sections not made
unique for different object files. Fixed and tested working for both
-fgpu-rdc and -fno-gpu-rdc case with and without -r
This reverts commit 897ccddcc30cacdfe04ddd622986b50ec963eabc. It
introduced a bug when formatting multiple files in one go. When a
shorter file is passed after a longer one, a stale length from the
previous file seems to be used, triggering an "invalid length (...) is
outside the file" error.
This PR adds support for the DLTI dialect by attaching it to the module
attributes and introduces a utility function to determine if the target
is big-endian, which is required for
https://github.com/llvm/llvm-project/pull/142041. Some tests were
updated because we now use `mlir::translateDataLayout`, which "updates"
the `DataLayout` where the alignment for `long` is 8 instead of the
previously 4. This updated is consistent with Incubator.
We have multiple different attributes in clang representing device
kernels for specific targets/languages. Refactor them into one attribute
with different spellings to make it more easily scalable for new
languages/targets.
---------
Signed-off-by: Sarnie, Nick <nick.sarnie@intel.com>
This PR add functionality to change `flang` command line using
environment variable `FCC_OVERRIDE_OPTIONS`. It is quite similar to what
`CCC_OVERRIDE_OPTIONS` does for clang.
The `FCC_OVERRIDE_OPTIONS` seemed like the most obvious name to me but I
am open to other ideas. The `applyOverrideOptions` now takes an extra
argument that is the name of the environment variable. Previously
`CCC_OVERRIDE_OPTIONS` was hardcoded.
This reverts commit ea1bfbf3f6399b7d2d840722f0e87542d00f6a35.
The commit did not solve the fundamental issue we need to handle and is
no longer necessary.
rdar://144794793
This reverts commit e2a885537f11f8d9ced1c80c2c90069ab5adeb1d. Build failures were fixed right away and reverting the original commit without the fixes breaks the build again.
The `DiagnosticOptions` class is currently intrusively
reference-counted, which makes reasoning about its lifetime very
difficult in some cases. For example, `CompilerInvocation` owns the
`DiagnosticOptions` instance (wrapped in `llvm::IntrusiveRefCntPtr`) and
only exposes an accessor returning `DiagnosticOptions &`. One would
think this gives `CompilerInvocation` exclusive ownership of the object,
but that's not the case:
```c++
void shareOwnership(CompilerInvocation &CI) {
llvm::IntrusiveRefCntPtr<DiagnosticOptions> CoOwner = &CI.getDiagnosticOptions();
// ...
}
```
This is a perfectly valid pattern that is being actually used in the
codebase.
I would like to ensure the ownership of `DiagnosticOptions` by
`CompilerInvocation` is guaranteed to be exclusive. This can be
leveraged for a copy-on-write optimization later on. This PR changes
usages of `DiagnosticOptions` across `clang`, `clang-tools-extra` and
`lldb` to not be intrusively reference-counted.
Add a linker test for -Bsymbolic-functions to AddLLVM and remove
the illumos hardcoded bits for its handling. OpenBSD also has a
local patch for linking with the old BFD linker on mips64 and
sparc64.
Fixes#139375
Clang expects command line source locations to be provided using 1-based
indexing.
Currently, Clang does not reject zero as invalid argument for column or
line number, which can cause Clang to crash.
This commit extends validation in `ParsedSourceLocation::FromString` to
only accept (unsinged) non-zero integers.
This PR adds the `%sdk/SDKSettings.json` file to the PCM input file
table, so that the PCM gets invalidated when the file changes. This is
necessary for availability checks to work correctly.
This PR adds support for AOT compilation for Intel CPUs and GPUs in
clang-sycl-linker. When no `-arch` is passed to `clang-sycl-linker`, the
output of the tool will be the resulting linked SPIR-V bytecode. If the
`-arch` is passed to `clang-sycl-linker` and the value is a supported
Intel CPU or GPU, then SPIR-V bytecode is then further passed to the
respective tool (`opencl-aot` or `ocloc`) for AOT compilation.
- Defines a new declaration node `HLSLRootSignature` in `DeclNodes.td`
that will consist of a `TrailingObjects` of the in-memory construction
of the root signature, namely an array of `hlsl::rootsig::RootElement`s
- Defines a new clang attr `RootSignature` which simply holds an
identifier to a corresponding root signature declaration as above
- Integrate the `HLSLRootSignatureParser` to construct the decl node in
`ParseMicrosoftAttributes` and then attach the parsed attr with an
identifier to the entry point function declaration.
- Defines the various required declaration methods
- Add testing that the declaration and reference attr are created
correctly, and some syntactical error tests.
It was previously proposed that we could have the root elements
reference be stored directly as an additional member of the attribute
and to not have a separate root signature decl. In contrast, by defining
them separately as this change proposes, we will allow a unique root
signature to have its own declaration in the AST tree. This allows us to
only construct a single root signature for all duplicate root signature
attributes. Having it located directly as a declaration might also prove
advantageous when we consider root signature libraries.
Resolves https://github.com/llvm/llvm-project/issues/119011
With the introduction of tbd-v5 holding rpaths, the order in which those
attributes are passed to `clang-installapi` must be represented in tbd
files. Previously, all dylib attributes were stored in a
non-deterministic `StringMap`. Instead, hold them in a custom collection
with an underlying vector to continue supporting searching by attribute.
This makes the order of all diagnostics related to load command
comparisons stable.
This approach resolves errors when building with reverse-iteration.
