This patch avoids unnecessarily copying contents of `mmap`-ed files into `CachedFileSystemEntry` by storing `MemoryBuffer` instead. The change leads to ~50% reduction of peak memory footprint when scanning LLVM+Clang via `clang-scan-deps`.
Depends on D115331.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D115043
Most of `MemoryBuffer` interfaces expose a `RequiresNullTerminator` parameter that's being used to:
* determine how to open a file (`mmap` vs `open`),
* assert newly initialized buffer indeed has an implicit null terminator.
This patch adds the paramater to the `SmallVectorMemoryBuffer` constructors, meaning:
* null terminator can now be added to `SmallVector`s that didn't have one before,
* `SmallVectors` that had a null terminator before keep it even after the move.
In line with existing code, the new parameter is defaulted to `true`. This patch makes sure all calls to the `SmallVectorMemoryBuffer` constructor set it to `false` to preserve the current semantics.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D115331
This patch changes uses of `std::unique_lock` to `std::lock_guard`.
The `std::unique_lock` template provides some advanced capabilities (deferred locking, time-constrained locking attempts, etc.) we don't use in the caching filesystem. Plain `std::lock_guard` will do here.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D115332
I found that the coroutine intrinsic llvm.coro.param in documentation
(https://llvm.org/docs/Coroutines.html#id101) didn't get used actually
since there isn't lowering codes in LLVM. I also checked the
implementation of libstdc++ and libc++. Both of them didn't use
llvm.coro.param. So I am pretty sure that the llvm.coro.param intrinsic
is unused. I think it would be better t to remove it to avoid possible
misleading understandings.
Note: according to [class.copy.elision]/p1.3, this optimization is
allowed by the C++ language specification. Let's make it someday.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D115222
Previously we would create global module fragment for extern linkage
declaration which is alreday in global module fragment. However, it is
clearly redundant to do so. This patch would check if the extern linkage
declaration are already in GMF before we create a GMF for it.
Update `OpenMPIRBuilder::collapseLoops()` to call `resize()` instead of
`set_size()`. The latter asserts on capacity limits and cannot grow,
which seems likely to be unintentional here (if it is, I think a local
assertion would be good for clarity).
Also update `CodeGenFunction::EmitOMPCollapsedCanonicalLoopNest()` to
use `pop_back_n()` instead of `set_size()`.
Differential Revision: https://reviews.llvm.org/D115378
This patch translates HIP kernels to SPIR-V kernels when the HIP
compilation mode is targeting SPIR-S. This involves:
* Setting Cuda calling convention to CC_OpenCLKernel (which maps to
SPIR_KERNEL in LLVM IR later on).
* Coercing pointer arguments with default address space (AS) qualifier
to CrossWorkGroup AS (__global in OpenCL). HIPSPV's device code is
ultimately SPIR-V for OpenCL execution environment (as
starter/default) where Generic or Function (OpenCL's private) is not
supported as storage class for kernel pointer types. This leaves the
CrossWorkGroup to be the only reasonable choice for HIP buffers.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D109818
Some command-line codegen arguments are likely to differ between identical modules discovered from different translation units. This patch removes them to make builds deterministic and/or reduce the number of built modules.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D112923
This patch implements the following:
- Emit PACBTI-M build attributes in libunwind asm files
- Authenticate LR in DWARF32 using PACBTI
Use Armv8.1-M.Main PACBTI extension to authenticate the return address
(stored in the LR register) before moving it to the PC (IP) register.
The AUTG instruction is used with the candidate return address, the CFA,
and the authentication code that is retrieved from the saved
pseudo-register RA_AUTH_CODE.
- Authenticate LR in EHABI using PACBTI
Authenticate the contents of the LR register using Armv8.1-M.Main PACBTI
extension.
A new frame unwinding instruction is introduced (0xb4). This
instruction pops out of the stack the return address authentication
code, which is then used in conjunction with the SP and the next-to-be
instruction pointer to perform authentication.
This authentication code is popped into a new register,
UNW_ARM_PSEUDO_PAC, which is a pseudo-register.
This patch is part of a series that adds support for the PACBTI-M extension of
the Armv8.1-M architecture, as detailed here:
https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-1-m-pointer-authentication-and-branch-target-identification-extension
The PACBTI-M specification can be found in the Armv8-M Architecture Reference
Manual:
https://developer.arm.com/documentation/ddi0553/latest
The following people contributed to this patch:
- Momchil Velikov
- Victor Campos
- Ties Stuij
Reviewed By: #libunwind, danielkiss, mstorsjo
Differential Revision: https://reviews.llvm.org/D112430
The compiler would judge two concepts is same by their addresses.
However, when we use modules, the addresses wouldn't be the same all the
time since one is parsed in their TU and another is imported in another
TU.
This patch fixes this by using isSameEntity to judge the two concepts.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D114769
According to [basic.namespace.general]/p2, a namespace declaration
shouldn't have a module linkage.
> A namespace is never attached to a named module and never has a name
> with module linkage.
Without this patch, the compiler would crash for the test in assertion
enabled build due to inconsistent linkage for redeclaration for
namespaces.
Reviewed by: rsmith
Differential Revision: https://reviews.llvm.org/D115132
According to [module.unit]p7.2.3, a declaration within a linkage-specification
should be attached to the global module.
This let user to forward declare types across modules.
Reviewed by: rsmith, aaron.ballman
Differential Revision: https://reviews.llvm.org/D110215
Add desugared type to hover when the desugared type and the pretty-printed type are different.
```c++
template<typename T>
struct TestHover {
using Type = T;
};
int main() {
TestHover<int>::Type a;
}
```
```
variable a
Type: TestHover<int>::Type (aka int)
```
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D114522
A series of unary operators and casts may obscure the variable we're
trying to analyze. Ignore them for the uninitialized value analysis.
Other checks determine if the unary operators result in a valid l-value.
Link: https://github.com/ClangBuiltLinux/linux/issues/1521
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D114848
This fixes in a regression introduced by 6eeda06c1.
When deducing the return type of nested function calls, only the
return type of the outermost expression should be ignored.
Instead of assuming all contextes nested in a discared statements
are themselves discarded, only assume that in immediate contexts.
Similarly, only consider contextes immediately in an immediate or
discarded statement as being themselves immediate.
Some users have a need to control attribute extension diagnostics
independent of other extension diagnostics. Consider something like use
of [[nodiscard]] within C++11:
```
[[nodiscard]]
int f();
```
If compiled with -Wc++17-extensions enabled, this will produce warning:
use of the 'nodiscard' attribute is a C++17 extension. This diagnostic
is correct -- using [[nodiscard]] in C++11 mode is a C++17 extension.
And the behavior of __has_cpp_attribute(nodiscard) is also correct --
we support [[nodiscard]] in C++11 mode as a conforming extension. But
this makes use of -Werror or -pedantic-errors` builds more onerous.
This patch adds diagnostic groups for attribute extensions so that
users can selectively disable attribute extension diagnostics. I
believe this is preferable to requiring users to specify additional
flags because it means -Wc++17-extensions continues to be the way we
enable all C++17-related extension diagnostics. It would be quite easy
for someone to use that flag thinking they're protected from some
portability issues without realizing it skipped attribute extensions if
we went the other way.
This addresses PR33518.
The default for min is changed to 1. The behaviour of -mvscale-{min,max}
in Clang is also changed such that 16 is the max vscale when targeting
SVE and no max is specified.
Reviewed By: sdesmalen, paulwalker-arm
Differential Revision: https://reviews.llvm.org/D113294
Select the OpenCLKernel calling convention for kernels when compiling
CUDA targeting SPIR-V.
In this way the generated LLVM IR will have a spir_kernel calling
convention that will be translated to an OpEntryPoint when converting
to SPIRV.
Reviewed By: jlebar, tra
Differential Revision: https://reviews.llvm.org/D114407
This patch fixes issues for -fgpu-rdc for Windows MSVC
toolchain:
Fix COFF specific section flags and remove section types
in llvm-mc input file for Windows.
Escape fatbin path in llvm-mc input file.
Add -triple option to llvm-mc.
Put __hip_gpubin_handle in comdat when it has linkonce_odr
linkage.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D115039
Declaration context of template parameters of a FunctionTemplateDecl
may be different for each one parameter if the template is a
deduction guide. This case is handled correctly after this change.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D114418
WG14 adopted the _ExtInt feature from Clang for C23, but renamed the
type to be _BitInt. This patch does the vast majority of the work to
rename _ExtInt to _BitInt, which accounts for most of its size. The new
type is exposed in older C modes and all C++ modes as a conforming
extension. However, there are functional changes worth calling out:
* Deprecates _ExtInt with a fix-it to help users migrate to _BitInt.
* Updates the mangling for the type.
* Updates the documentation and adds a release note to warn users what
is going on.
* Adds new diagnostics for use of _BitInt to call out when it's used as
a Clang extension or as a pre-C23 compatibility concern.
* Adds new tests for the new diagnostic behaviors.
I want to call out the ABI break specifically. We do not believe that
this break will cause a significant imposition for early adopters of
the feature, and so this is being done as a full break. If it turns out
there are critical uses where recompilation is not an option for some
reason, we can consider using ABI tags to ease the transition.
Previously, the `SValBuilder` could not encounter expressions of the
following kind:
NonLoc OP Loc
Loc OP NonLoc
Where the `Op` is other than `BO_Add`.
As of now, due to the smarter simplification and the fixedpoint
iteration, it turns out we can.
It can happen if the `Loc` was perfectly constrained to a concrete
value (`nonloc::ConcreteInt`), thus the simplifier can do
constant-folding in these cases as well.
Unfortunately, this could cause assertion failures, since we assumed
that the operator must be `BO_Add`, causing a crash.
---
In the patch, I decided to preserve the original behavior (aka. swap the
operands (if the operator is commutative), but if the `RHS` was a
`loc::ConcreteInt` call `evalBinOpNN()`.
I think this interpretation of the arithmetic expression is closer to
reality.
I also tried naively introducing a separate handler for
`loc::ConcreteInt` RHS, before doing handling the more generic `Loc` RHS
case. However, it broke the `zoo1backwards()` test in the `nullptr.cpp`
file. This highlighted for me the importance to preserve the original
behavior for the `BO_Add` at least.
PS: Sorry for introducing yet another branch into this `evalBinOpXX`
madness. I've got a couple of ideas about refactoring these.
We'll see if I can get to it.
The test file demonstrates the issue and makes sure nothing similar
happens. The `no-crash` annotated lines show, where we crashed before
applying this patch.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D115149
Before, the CLANG_DEFAULT_LINKER cmake option was a global override for
the linker that shall be used on all toolchains. The linker binary
specified that way may not be available on toolchains with custom
linkers. Eg, the only linker for VE is named 'nld' - any other linker
invalidates the toolchain.
This patch removes the hard override and instead lets the generic
toolchain implementation default to CLANG_DEFAULT_LINKER. Toolchains
can now deviate with a custom linker name or deliberatly default to
CLANG_DEFAULT_LINKER.
Reviewed By: MaskRay, phosek
Differential Revision: https://reviews.llvm.org/D115045
This documentation supports the dataflow analysis framework (see "[RFC]
A dataflow analysis framework for Clang AST" on cfe-dev).
Since the implementation of the framework has not been committed yet,
right now the doc describes dataflow analysis in general.
Since this is the first markdown document in clang/docs, I added support
for Markdown to clang/docs/conf.py in the same way as it is done in
llvm/docs.
Reviewed By: xazax.hun
Differential Revision: https://reviews.llvm.org/D114231
Ties Stuij