Currently, the UnifiedLTO pipeline seems to have trouble with several
LTO features, like SplitLTO units, which means we cannot use important
optimizations like Whole Program Devirtualization or security hardening
instrumentation like CFI.
This patch reverts FatLTO to using distinct pipelines for Full LTO and
ThinLTO. It still avoids module cloning, since that was error prone.
* Set `__cpp_auto_cast`, as per
https://github.com/cplusplus/CWG/issues/281
* Support `__has_extension(cxx_generalized_nttp)` in C++20 as the
feature isn't stable enough for a feature test macro
* Support `__has_extension(cxx_explicit_this_parameter)` in c++23 as the
feature isn't stable enough for a feature test macro
This follows the same implementation logic as with C++ and is
compatible with the GCC behavior in C.
Trigraphs are enabled by default in -std=c* conformance modes before
C23, but are disabled in GNU and Microsoft modes as well as in C23 or
later.
Add support for specifying the logical SPIR-V target environment in the
triple as Vulkan. When compiling HLSL, this replaces the DirectX Shader
Model with a Vulkan environment instead.
Currently, the only supported combinations of SPIR-V version and Vulkan
environment are:
- Vulkan 1.2 and SPIR-V 1.5
- Vulkan 1.3 and SPIR-V 1.6
Fixes#70051
Prior to this commit, it was impossible to use the simple string
matching directives to look for any content that contains unbalanced
`{{` `}}` pairs, such as:
```
// expected-note {{my_struct{{1}, 2}}}
```
Which would parse like so:
```
"nested" brace v
// expected-note {{my_struct{{1}, 2}}}
closes the nested brace ^ |
trailing }
```
And the frontend would complain 'cannot find end ('}}') of expected'.
At this snapshot, VerifyDiagnosticConsumer's parser now counts the
opening braces and looks for a matching length of closing sigils,
allowing the above to be written as:
```
// expected-note {{{my_struct{{1}, 2}}}}
opening brace |-| |-|
closing brace is '}}}', found here ^
```
This came about as a result of this discussion:
https://github.com/llvm/llvm-project/pull/74852#discussion_r1443117644
cc @erichkeane
This PR exposes four PGO functions
- `__llvm_profile_set_filename`
- `__llvm_profile_reset_counters`,
- `__llvm_profile_dump`
- `__llvm_orderfile_dump`
to user programs through the new header `instr_prof_interface.h` under
`compiler-rt/include/profile`. This way, the user can include the header
`profile/instr_prof_interface.h` to introduce these four names to their
programs.
Additionally, this PR defines macro `__LLVM_INSTR_PROFILE_GENERATE` when
the program is compiled with profile generation, and defines macro
`__LLVM_INSTR_PROFILE_USE` when the program is compiled with profile
use. `__LLVM_INSTR_PROFILE_GENERATE` together with
`instr_prof_interface.h` define the PGO functions only when the program
is compiled with profile generation. When profile generation is off,
these PGO functions are defined away and leave no trace in the user's
program.
Background:
https://discourse.llvm.org/t/pgo-are-the-llvm-profile-functions-stable-c-apis-across-llvm-releases/75832
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
Add an extension feature `define-target-os-macros` that enables clang to
provide definitions of common TARGET_OS_* conditional macros. The
extension is enabled in the Darwin toolchain driver.
Summary:
The standard GNU atomic operations are a very common way to target
hardware atomics on the device. With more heterogenous devices being
introduced, the concept of memory scopes has been in the LLVM language
for awhile via the `syncscope` modifier. For targets, such as the GPU,
this can change code generation depending on whether or not we only need
to be consistent with the memory ordering with the entire system, the
single GPU device, or lower.
Previously these scopes were only exported via the `opencl` and `hip`
variants of these functions. However, this made it difficult to use
outside of those languages and the semantics were different from the
standard GNU versions. This patch introduces a `__scoped_atomic` variant
for the common functions. There was some discussion over whether or not
these should be overloads of the existing ones, or simply new variants.
I leant towards new variants to be less disruptive.
The scope here can be one of the following
```
__MEMORY_SCOPE_SYSTEM // All devices and systems
__MEMORY_SCOPE_DEVICE // Just this device
__MEMORY_SCOPE_WRKGRP // A 'work-group' AKA CUDA block
__MEMORY_SCOPE_WVFRNT // A 'wavefront' AKA CUDA warp
__MEMORY_SCOPE_SINGLE // A single thread.
```
Naming consistency was attempted, but it is difficult to capture to full
spectrum with no many names. Suggestions appreciated.
It simply wastes of space and time to write diagnostic options, header
search paths and pragma diagnostic mappings for C++20 Named modules.
This patch tries to avoid the unnecessary writings.
CodeGen options do not affect the AST, so they usually can be ignored.
The only exception to the rule is when a PCM is created with
`-gmodules`.
In that case the Clang module format is switched to object file
container and contains also serialized debug information that can be
affected by debug options. There the following approach was choosen:
1.) Split out all the debug options into a separate `DebugOptions.def`
file. The file is included by `CodeGenOptions.def`, so the change is
transparent to all existing users of `CodeGenOptions.def`.
2.) Reset all CodeGen options, but excluding affecting debug options.
3.) Conditionally reset debug options that can affect the PCM.
This fixes rdar://113135909.
CodeGen options do not affect the AST, so they usually can be ignored.
The only exception to the rule is when a PCM is created with
`-gmodules`.
In that case the Clang module format is switched to object file
container and contains also serialized debug information that can be
affected by debug options. There the following approach was choosen:
1.) Split out all the debug options into a separate `DebugOptions.def`
file. The file is included by `CodeGenOptions.def`, so the change is
transparent to all existing users of `CodeGenOptions.def`.
2.) Reset all CodeGen options, but excluding affecting debug options.
3.) Conditionally reset debug options that can affect the PCM.
This fixes rdar://113135909.
https://github.com/llvm/llvm-project/issues/70703 pointed out that
cloning LLVM modules could lead to miscompiles when using FatLTO.
This is due to an existing issue when cloning modules with labels (see
#55991 and #47769). Since this can lead to miscompilation, we can avoid
cloning the LLVM modules, which was desirable anyway.
This patch modifies the EmbedBitcodePass to no longer clone the module
or run an input pipeline over it. Further, it make FatLTO always perform
UnifiedLTO, so we can still defer the Thin/Full LTO decision to
link-time. Lastly, it removes dead/obsolete code related to now defunct
options that do not work with the EmbedBitcodePass implementation any
longer.
This upstreams more of the Clang API Notes functionality that is
currently implemented in the Apple fork:
https://github.com/apple/llvm-project/tree/next/clang/lib/APINotes
This adds the initial Clang APINotes infrastructure to Clang Sema and
Clang Frontend.
There will shortly be a follow-up patch with the actual usages of this
API. I'm splitting these changes into separate PRs to keep the diffs
easier to review.
Initial commits to support OpenACC. This patchset:
adds a clang-command line argument '-fopenacc', and starts
to define _OPENACC, albeit to '1' instead of the standardized
value (since we don't properly implement OpenACC yet).
The OpenACC spec defines `_OPENACC` to be equal to the latest standard
implemented. However, since we're not done implementing any standard,
we've defined this by default to be `1`. As it is useful to run our
compiler against existing OpenACC workloads, we're providing a
temporary override flag to change the `_OPENACC` value to be any
entirely digit value, permitting testing against any existing OpenACC
project.
Exactly like the OpenMP parser, the OpenACC pragma parser needs to
consume and reprocess the tokens. This patch sets up the infrastructure
to do so by refactoring the OpenMP version of this into a more general
version that works for OpenACC as well.
Additionally, this adds a few diagnostics and token kinds to get us
started.
Close https://github.com/llvm/llvm-project/issues/71347
Previously I misread the concept of module purview. I thought if a
declaration attached to a unnamed module, it can't be part of the module
purview. But after the issue report, I recognized that module purview is
more of a concept about locations instead of semantics.
Concretely, the things in the language linkage after module declarations
can be exported.
This patch refactors `Module::isModulePurview()` and introduces some
possible code cleanups.
This reverts commit 578a4716f549167165a2ec3bac89c86706136d4e.
This causes multiple issues. Compile time slowdown due to more path
canonicalization, and weird behavior on Windows.
Will reland under a separate flag `-f[no-]canonical-system-headers` to
match gcc in the future and further limit when it's passed by default.
Fixes#70011.
This patch converts `StringLiteral::StringKind` to a scoped enum in namespace scope. This enabled forward-declarations of this enum where necessary, e.g. for `preferred_type` annotation for bit-fields.
Deserialization of the `DIAGNOSTIC_OPTIONS` and `HEADER_SEARCH_PATHS`
records is slow and done for every transitively loaded PCM.
Deserialization of these records cannot be skipped, because the words
are VBR6-encoded and we don't store the length of the entire record. We
could either turn them into binary blobs that can be skipped during
deserialization, or skip writing them altogether. This patch takes the
latter approach, since these records are not necessary in scanning PCMs.
The scanner doesn't make any guarantees about the accuracy of
diagnostics, and we always have the same header search paths due to
strict context hashing.
The commit that makes the `DIAGNOSTIC_OPTIONS` record skippable was
originally implemented by @benlangmuir in a downstream repo.
This upstreams more of the Clang API Notes functionality that is
currently implemented in the Apple fork:
https://github.com/apple/llvm-project/tree/next/clang/lib/APINotes
This adds the first compiler options related to API Notes to the
upstream Clang: `-iapinotes-modules` and `-fapinotes-swift-version=`.
However, this does not add the `-fapinotes` flag that enables API Notes,
since the feature is not fully functional yet.
This patch moves `ObjCMethodDecl::ImplementationControl` to a DeclBase.h so that it's complete at the point where corresponsing bit-field is declared. This patch also converts it to a scoped enum `clang::ObjCImplementationControl`.
This patch moves `ArraySizeModifier` before `Type` declaration so that it's complete at `ArrayTypeBitfields` declaration. It's also converted to scoped enum along the way.
-fmodule-file=<module-name>= option
Currently if we have multiple `-fmodule-file=<module-name>=<BMI-path>`
flags for the same `<module-name>`, we will pick the BMI-path from the
first flag. And this is inconsistent with what users generally expect.
e.g, we might expect the latter flags can override the former ones.
This patch changes the behavior to match user's expectation.
The `-include "file"` option implicitly adds a leading #include
to the main source; however, there's no explicit #include, which
left -frewrite-includes emitting an unmatched #endif at the end
of the included text.
This corrects a bug in 4a16b51f.
This patch adds `CC_M68kRTD`, which will be used on function if either
`__attribute__((m68k_rtd))` is presented or `-mrtd` flag is given.
Differential Revision: https://reviews.llvm.org/D149867
Now that llvm::support::endianness has been renamed to
llvm::endianness, we can use the shorter form. This patch replaces
llvm::support::endianness with llvm::endianness.
The `Module` parameter to `checkModuleIsAvailable` is currently passed
by pointer to non-const. However, it requires only const access and it
cannot be null. Change this to be a reference to const instead.
This then makes it obvious that it is an input-only parameter, so move
it to be before the in-out parameter for diagnostics.
This option will cause -E to preserve the #include directives
for system headers, rather than expanding them into the output.
This can greatly reduce the volume of preprocessed source text
in a test case, making test case reduction simpler.
Note that -fkeep-system-includes is not always appropriate. For
example, if the problem you want to reproduce is induced by a
system header file, it's better to expand those headers fully.
If your source defines symbols that influence the content of a
system header (e.g., _POSIX_SOURCE) then -E will eliminate the
definition, potentially changing the meaning of the preprocessed
source. If you use -isystem to point to non-system headers, for
example to suppress warnings in third-party software, those will
not be expanded and might make the preprocessed source less useful
as a test case.
The #if now has a conditional expression, so a user can add
`-D__CLANG_REWRITTEN_SYSTEM_INCLUDES` to include the system headers
instead of using the expanded content, or
`-D__CLANG_REWRITTEN_INCLUDES` to include all headers.
Also added the filename to the comments it emits, to help identify where
included text ends, making it easier to identify and remove the content of
individual headers.
This reverts commit a6acf3fd49a20c570a390af2a3c84e10b9545b68 and
relands a50e63b38b931d945f97eac882278068221eca17. The original revert
was done by mistake.
The issue #53952 is reported indicating clang is giving a crashing pch
file, when hasErrors is been passed incorrectly to WriteAST method.
To fix the issue, the parameter has been removed and instead we're
relying on the results of `hasUncompilableErrorOccured()` instead of
letting the caller override it.
Fixes https://github.com/llvm/llvm-project/issues/53952
