| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
std::get free function (#122265)
When we generate the debug-info for a `VarDecl` we try to determine
whether it was introduced as part of a structure binding (aka a "holding
var"). If it was then we don't mark it as `artificial`.
The heuristic to determine a holding var uses
`IgnoreUnlessSpelledInSource` to unwrap the `VarDecl` initializer until
we hit a `DeclRefExpr` that refers to a `Decomposition`. For "tuple-like
decompositions", Clang will generate a call to a `template<size_t I> Foo
get(Bar)` function that retrieves the `Ith` element from the tuple-like
structure. If that function is a member function, we get an AST that
looks as follows:
```
VarDecl implicit used z1 'std::tuple_element<0, B>::type &&' cinit
`-ExprWithCleanups <col:10> 'int' xvalue
`-MaterializeTemporaryExpr <col:10> 'int' xvalue extended by Var 0x11d110cf8 'z1' 'std::tuple_element<0, B>::type &&'
`-CXXMemberCallExpr <col:10> 'int'
`-MemberExpr <col:10> '<bound member function type>' .get 0x11d104390
`-ImplicitCastExpr <col:10> 'B' xvalue <NoOp>
`-DeclRefExpr <col:10> 'B' lvalue Decomposition 0x11d1100a8 '' 'B'
```
`IgnoreUnlessSpelledInSource` happily unwraps this down to the
`DeclRefExpr`. However, when the `get` helper is a free function (which
it is for `std::pair` in libc++ for example), then the AST is:
```
VarDecl col:16 implicit used k 'std::tuple_element<0, const std::tuple<int, int>>::type &' cinit
`-CallExpr <col:16> 'const typename tuple_element<0UL, tuple<int, int>>::type':'const int' lvalue adl
|-ImplicitCastExpr <col:16> 'const typename tuple_element<0UL, tuple<int, int>>::type &(*)(const tuple<int, int> &) noexcept' <FunctionToPointerDecay>
| `-DeclRefExpr <col:16> 'const typename tuple_element<0UL, tuple<int, int>>::type &(const tuple<int, int> &) noexcept' lvalue Function 0x1210262d8 'get' 'const typename tuple_element<0UL, tuple<int, int>>::type &(const tuple<int, int> &) noexcept' (FunctionTemplate 0x11d068088 'get')
`-DeclRefExpr <col:16> 'const std::tuple<int, int>' lvalue Decomposition 0x121021518 '' 'const std::tuple<int, int> &'
```
`IgnoreUnlessSpelledInSource` doesn't unwrap this `CallExpr`, so we
incorrectly mark the binding as `artificial` in debug-info.
This patch adjusts `IgnoreUnlessSpelledInSource` so it unwraps implicit
`CallExpr`s. It's almost identical to how we treat implicit constructor
calls (unfortunately the code can't quite be re-used because a
`CXXConstructExpr` is-not a `CallExpr`, and we check `isElidable`, which
doesn't exist for regular function calls. So I added a new
`IgnoreImplicitCallSingleStep`).
Fixes https://github.com/llvm/llvm-project/issues/122028
|
|
This change adds support for type promotion for VectorType
Issue https://github.com/llvm/llvm-project/issues/136487
|
|
This patch adds atomic exchange operation which covers the following
C/C++ intrinsic functions:
- `__c11_atomic_exchange`
- `__atomic_exchange`
- `__atomic_exchange_n`
|
|
Fix the Missing enum element `Decl::OMPGroupPrivate` warning
|
|
Close https://github.com/llvm/llvm-project/issues/159780
|
|
|
|
#159505 (#159859)
We can't give a correct answer for dependent types, so for now just
report no ptrauth involves if the type being queried is dependent. In
future we may want to distinguigh the `None` vs `Dependent` cases but
that does not seem warranted for now.
Fixes #159505
|
|
(#159771)
Fixes #159768.
When building a named module interface with `-fmodules` enabled,
importing a Clang module from inside the global module fragment causes
Clang to crash only on assertion builds.
This fixes the assert and extends the test coverage.
|
|
This patchs implements array constructors and destructors for
multidimensional arrays. This works by bitcasting the pointer to the
first element to a one-dimensional array type of the same extent before
lowering to a loop.
|
|
This PR ensures that the Clang static analyzer loads the config file
through the properly-configured VFS rather than through the bare real
file system. This enables correctly going through VFS overlays, unifying
the behavior with the rest of the compiler.
|
|
This makes sure the tuple sizes remain within implementation limits, and
this doesn't cause the compiler to crash later, as the tuple size is
assumed to fit within an UnsignedOrNone.
Fixes #159563
|
|
This change adds support for local AND op for VectorType
Issue https://github.com/llvm/llvm-project/issues/136487
|
|
This makes the UEFI driver's handling of linking more canonical
in a few ways:
* Use /option:value syntax with lld-link as in the MSVC driver.
* Handle -nostdlib, -nodefaultlibs, -r and call common
subroutines when they aren't set. This covers sanitizer and
profile runtimes and their associated switches; compiler-rt
builds do not yet provide these libraries, but the driver
behavior is opt-in and supports all the opt-in/out plumbing
like other targets do. This lets command lines immediately
use the opt-out switches even when they are superfluous for
opt-in features, as build system plumbing often needs to do.
It also updates some TODO comments for how the driver behavior
will look when more runtime support is ready.
|
|
This fixes a regression reported here:
https://github.com/llvm/llvm-project/pull/159463#issuecomment-3312157416
Since this regression was never released, there are no release notes.
|
|
Add deprecation warnings to compatability overloads and add tests to
show the warnings.
Closes #133452
|
|
This change adds support for TypeInfoAttr which is needed later for RTTI
in exceptions
Issue https://github.com/llvm/llvm-project/issues/154992
|
|
Optimize lifetime safety analysis performance
- Added early return optimization in `join` function for ImmutableSet
when sets are identical
- Improved ImmutableMap join logic to avoid unnecessary operations when
values are equal
I was under the impression that ImmutableSets/Maps would not modify the
underlying if already existing elements are added to the container (and
was hoping for structural equality in this aspect). It looks like the
current implementation of `ImmutableSet` would perform addition
nevertheless thereby creating (presumably `O(log(N))` tree nodes.
This change considerably brings down compile times for some edge cases
which happened to be present in the LLVM codebase. Now it is actually
possible to compile LLVM in under 20 min with the lifetime analysis.
The compile time hit is still significant but not as bad as before this
change where it was not possible to compile LLVM without severely
limiting analysis' scope (giving up on CFG with > 3000 blocks).
Fixes https://github.com/llvm/llvm-project/issues/157420
<details>
<summary>Report (Before)</summary>
</details>
<details>
<summary>Report (After)</summary>
# Lifetime Analysis Performance Report
> Generated on: 2025-09-18 14:28:00
---
## Test Case: Pointer Cycle in Loop
**Timing Results:**
| N (Input Size) | Total Time | Analysis Time (%) | Fact Generator (%) |
Loan Propagation (%) | Expired Loans (%) |
|:---------------|-----------:|------------------:|-------------------:|---------------------:|------------------:|
| 25 | 53.76 ms | 85.58% | 0.00% | 85.46% | 0.00% |
| 50 | 605.35 ms | 98.39% | 0.00% | 98.37% | 0.00% |
| 75 | 2.89 s | 99.62% | 0.00% | 99.61% | 0.00% |
| 100 | 8.62 s | 99.80% | 0.00% | 99.80% | 0.00% |
**Complexity Analysis:**
| Analysis Phase | Complexity O(n<sup>k</sup>) |
|:------------------|:--------------------------|
| Total Analysis | O(n<sup>3.82</sup> ± 0.01) |
| FactGenerator | (Negligible) |
| LoanPropagation | O(n<sup>3.82</sup> ± 0.01) |
| ExpiredLoans | (Negligible) |
---
## Test Case: CFG Merges
**Timing Results:**
| N (Input Size) | Total Time | Analysis Time (%) | Fact Generator (%) |
Loan Propagation (%) | Expired Loans (%) |
|:---------------|-----------:|------------------:|-------------------:|---------------------:|------------------:|
| 400 | 66.02 ms | 58.61% | 1.04% | 56.53% | 1.02% |
| 1000 | 319.24 ms | 81.31% | 0.63% | 80.04% | 0.64% |
| 2000 | 1.43 s | 92.00% | 0.40% | 91.32% | 0.28% |
| 5000 | 9.35 s | 97.01% | 0.25% | 96.63% | 0.12% |
**Complexity Analysis:**
| Analysis Phase | Complexity O(n<sup>k</sup>) |
|:------------------|:--------------------------|
| Total Analysis | O(n<sup>2.12</sup> ± 0.02) |
| FactGenerator | O(n<sup>1.54</sup> ± 0.02) |
| LoanPropagation | O(n<sup>2.12</sup> ± 0.03) |
| ExpiredLoans | O(n<sup>1.13</sup> ± 0.03) |
---
## Test Case: Deeply Nested Loops
**Timing Results:**
| N (Input Size) | Total Time | Analysis Time (%) | Fact Generator (%) |
Loan Propagation (%) | Expired Loans (%) |
|:---------------|-----------:|------------------:|-------------------:|---------------------:|------------------:|
| 50 | 137.30 ms | 90.72% | 0.00% | 90.42% | 0.00% |
| 100 | 1.09 s | 98.13% | 0.00% | 98.02% | 0.09% |
| 150 | 4.06 s | 99.24% | 0.00% | 99.18% | 0.05% |
| 200 | 10.44 s | 99.66% | 0.00% | 99.63% | 0.03% |
**Complexity Analysis:**
| Analysis Phase | Complexity O(n<sup>k</sup>) |
|:------------------|:--------------------------|
| Total Analysis | O(n<sup>3.29</sup> ± 0.01) |
| FactGenerator | (Negligible) |
| LoanPropagation | O(n<sup>3.29</sup> ± 0.01) |
| ExpiredLoans | O(n<sup>1.42</sup> ± 0.19) |
---
</details>
|
|
https://github.com/llvm/llvm-project/pull/121943 rewrote
`__atomic_test_and_set` and `__atomic_clear` to be lowered through
AtomicExpr
StmtPrinter::VisitAtomicExpr still treated them like other atomic
builtins with a Val1 operand. This led to incorrect pretty-printing when
dumping the AST.
Skip Val1 for these two builtins like atomic loads.
|
|
Fix two older FIXME items from the `functions.cpp` test.
|
|
Summary:
The added bit counting builtins for vectors used `cttz` and `ctlz`,
which is consistent with the LLVM naming convention. However, these are
clang builtins and implement exactly the `__builtin_ctzg` and
`__builtin_clzg` behavior. It is confusing to people familiar with other
other builtins that these are the only bit counting intrinsics named
differently. This includes the additional operation for the undefined
zero case, which was added as a `clzg` extension.
|
|
|
|
So the static invoker's Function still points to the static invoker
instead of the call operator of the lambda record. This is important for
a later commit.
|
|
the following changes are made
a)Typo Fix (with previous PRhttps://github.com/llvm/llvm-project/pull/155747)
b)builtins support for MIPS P8700 execution control instructions .
c)Testcase
|
|
`llvm::DenseMapInfo<llvm::FoldingSetNodeID>` (#159718)
In preparation of #141776
|
|
(#159694)
|
|
Add the support for OSObjectPtr, which behaves like RetainPtr.
|
|
|
|
std::ranges::all_of as [[clang::noescape]] (#158419)
The checker already had std::ranges hard-coded to treat its arguments as
[[clang::oescape]] but the fact std::ranges::all_of is implemented as a
struct instead of a function confused the checker and resuled in a
superflous warning being emitted for std::ranges::all_of.
This PR adds the support for recognizing DeclRefExpr which appears as a
callee in VisitCallExpr and generalizes the check in
shouldTreatAllArgAsNoEscape to walk up the decl contexts to find the
target namespaces such as std::ranges:: or a namespace and a function
like WTF::switchOn.
|
|
As Early As Possible (#159620)
Before this patch, we only perform `-D` canonicalization on the deep
copy of the `CompilerInvocation` instance, since the canonicalization
should have no impact on scanning.
However, in the presence of CAS, the content of the `builtin` macros are
included in the context hash. This patch makes sure that we canonicalize
the scanning `CompilerInvocation`'s `-D`s.
Part of work for rdar://136303612.
---------
Co-authored-by: Jan Svoboda <jan@svoboda.ai>
|
|
soft float ABI selection was not taking effect on little-endian powerPC
with embedded vectors (e.g. e500v2) leading to errors.
(embedded vectors use "extended" GPRs to store floating-point values,
and this caused issues with variadic arguments assuming dedicated
floating-point registers with hard-float ABI)
|
|
This PR passes the VFS down to `llvm::cl` functions so that they don't
assume the real file system.
|
|
(#157772)
Global resources are read-only. The compiler needs to report an error when somebody attempts to assign a value to a global resource, a global resource array element or the whole array.
Test update in `static-local-ctor.hlsl` includes the use of the llvm-cxxfilt tool which takes care of demangling of function names for a more readable test baseline.
Closes #154390
|
|
This patch makes sure constant template parameters are checked even in
dependent contexts.
This can for example diagnose narrowings earlier, but this is permitted
as these templates would have no valid instantiations.
|
|
This change adds support for local OR op for VectorType
Issue #136487
|
|
This PR makes the `VFS` parameter to `ASTUnit::LoadFromASTFile()`
required and explicit, rather than silently defaulting to the real file
system. This makes it easy to correctly propagate the fully-configured
VFS and load any input files like the rest of the compiler does.
|
|
Normalizing an empty modules cache path results in an incorrect
non-empty path (the working directory). This PR conditionalizes more
code to avoid this. Tested downstream by swift/llvm-project and the
`DependencyScanningCAPITests.DependencyScanningFSCacheOutOfDate` unit
test.
|
|
Support type promotion for Scalar unary plus & minus ops
|
|
This change adds support for type promotion in Scalar unary real & imag
ops
Issue: https://github.com/llvm/llvm-project/issues/141365
|
|
This change adds support for the OpaqueValueExpr for Complex in C
Issue: https://github.com/llvm/llvm-project/issues/141365
|
|
AVX/AVX512 subvector insertion intrinsics to be used in constexpr #157709 (#158778)
AVX/AVX512 vector insert intrinsics now support constexpr evaluation in both the AST evaluator and bytecode interpreter paths.
FIXES: #157709
|
|
|
|
Most lowering patterns have exactly the same class declaration with
different names and different `matchAndRewrite` implementations, yet
their declaration occupies near 1000 lines of code in `LowerToLLVM.h`,
making this file difficult to read and boring to maintain. In this
patch, I migrate their declarations to be generated from `CIROps.td`
using `clang-tblgen`. Some extra `CIR_Op` TableGen fields are introduced
to help this:
- The `CIR_Op` class now defines a `bit` field `hasLLVMLowering` which
defaults to `true`. If its value is `true`, `clang-tblgen` would
generate an LLVM lowering pattern declaration for the operation.
- Some LLVM lowering patterns has bounded recursion. This could be
enabled by setting the `isLLVMLoweringRecursive` field in a `CIR_Op`
record to `true`.
- Some LLVM lowering patterns have defined additional class members.
They could be listed in the `extraLLVMLoweringPatternDecl` field.
Note that in the incubator we have a similar TableGen code generator
that generates LLVM lowering code for CIR builtin ops which has a
one-to-one correspondence to LLVM dialect operations. This patch does
NOT try to upstream it.
Some additional noticeable changes made by this patch:
- This patch adds the `dataLayout` member to every LLVM lowering pattern
class to make the job easier for a code generator. In the future we
might want to add more members to the lowering patterns, and we will
need to update the code generator to make such changes.
|
|
Replace `StackChunk::End` with `StackChunk::Size`, mark the allocating
code paths as unlikely and move `grow()` into the header, which allows
us to template this for the `Size` parameter. Since we only push our
primitive types on the stack and all the sizes are aligned to pointer
size multiples, this only results in a few instantiations.
|
|
SPIR-V specific optimizations can inadvertently remove information that
is important for the AMDGPU BE / break certain code patterns we rely on.
Therefore, for AMDGCN flavoured SPIR-V we disable optimizations over IR,
to ensure that we operate directly on the output of Clang CodeGen when
we finalise.
|
|
(#159231)
Added constexpr to the remaining intrinsics:
_mm256_cvtepu16_ph
_mm256_mask_cvtepu16_ph
_mm256_maskz_cvtepu16_ph
_mm256_cvtepi32_ph
_mm256_mask_cvtepi32_ph
_mm256_maskz_cvtepi32_ph
_mm256_cvtepu32_ph
_mm256_mask_cvtepu32_ph
_mm256_maskz_cvtepu32_ph
Last part fixing #155798
|
|
They are only pointer-sized and copying them is cheaper than taking the
const ref.
|
|
extension/truncation intrinsics. (#158663)
The following AVX[512] intrinsics are now constexpr:
- `_mm512_mask_cvtepi8_epi32`
- `_mm512_maskz_cvtepi8_epi32`
- `_mm512_mask_cvtepi8_epi64`
- `_mm512_maskz_cvtepi8_epi64`
- ` _mm512_mask_cvtepi16_epi32`
- ` _mm512_maskz_cvtepi16_epi32`
- ` _mm512_mask_cvtepi16_epi64`
- ` _mm512_maskz_cvtepi16_epi64`
- ` _mm512_mask_cvtepi32_epi64`
- ` _mm512_maskz_cvtepi32_epi64`
- ` _mm512_mask_cvtepu8_epi32`
- ` _mm512_maskz_cvtepu8_epi32`
- ` _mm512_mask_cvtepu8_epi64`
- ` _mm512_maskz_cvtepu8_epi64`
- ` _mm512_mask_cvtepu16_epi32`
- ` _mm512_maskz_cvtepu16_epi32`
- `_mm512_mask_cvtepu16_epi64`
- `_mm512_maskz_cvtepu16_epi64`
- `_mm512_mask_cvtepu32_epi64`
- `_mm512_maskz_cvtepu32_epi64`
- `_mm512_mask_cvtepi8_epi16`
- `_mm512_maskz_cvtepi8_epi16`
- `_mm512_mask_cvtepu8_epi16`
- `_mm512_maskz_cvtepu8_epi16`
- `_mm_cvtepi16_epi8`
- `_mm256_cvtepi16_epi8`
- `_mm256_mask_cvtepi16_epi8`
- `_mm256_maskz_cvtepi16_epi8`
This PR is part 1 of a series of PRs fixing [#154539](https://github.com/llvm/llvm-project/issues/154539)
|
|
(#158134)
|
|
If it's truly a known const int, it won't emit any diagnostics anyway.
And if it did, we wouldn't notice because no call site passed something
non-null.
|
|
This patch updates the parsing changes to handle the new syntax of the
`uses_allocators` clause as defined in OpenMP 5.2(Section 6.8).
```
// Case 1: Allocator without traits
// < 5.2 → error
// ≥ 5.2 → OK, empty traits set
#pragma omp target teams uses_allocators(cgroup_alloc)
// Case 2: Allocator with traits
// Old syntax (< 5.2):
#pragma omp target teams uses_allocators(cgroup_alloc(cgroup_traits))
// New syntax (≥ 5.2):
#pragma omp target teams uses_allocators(traits(cgroup_traits) : cgroup_alloc)
// Case 3: Multiple allocators
// Old syntax (< 5.2), comma-separated:
#pragma omp target teams uses_allocators(cgroup_alloc(cgroup_traits), aligned_alloc(aligned_traits))
// New syntax (≥ 5.2), semicolon-separated:
#pragma omp target teams uses_allocators(traits(cgroup_traits) : cgroup_alloc; traits(aligned_traits) : aligned_alloc)
```
---------
Co-authored-by: urvi-rav <urvi.rav@hpe.com>
|
