This PR add stacktrace of escaped exception to
`bugprone-exception-escape` check.
Changes:
1. Modified `ExceptionAnalyzer` and `ExceptionInfo` classes to hold
stacktrace of escaped exception in `llvm::MapVector`. `llvm::MapVector`
is needed to hold relative positions of functions in stack as well as
have fast lookup.
2. Added new diagnostics based of `misc-no-recursion` check.
Fixes https://github.com/llvm/llvm-project/issues/87422.
The dependency directive scanner was incorrectly classifying namespaces
such as `import::inner xi` as directives. According to P1857R3, `import` should
not be treated as a directive when followed by `::`.
This change fixes that behavior.
According to the current LangRef, atomics of sizes larger than a
target-dependent limit are non-conformant IR. Presumably, that size
limit is `TargetLoweringBase::getMaxAtomicSizeInBitsSupported()`. As a
consequence, one would not even know whether IR is valid without
instantiating the Target backend.
To get around this, Clang's CGAtomic uses a constant "16 bytes" for the
maximally supported atomic. The verifier only checks the power-of-two
requirement.
In a discussion with jyknight, the intention is rather that the
AtomicExpandPass will just lower everything larger than the
target-supported atomic sizes to libcall (such as `__atomic_load`).
According to this interpretation, the size limit needs only be known by
the lowering and does not affect the IR specification.
The original "target-specific size limit" had been added in
59b66883eacbc62a09c09f08bcbfdce7af46cf31. The LangRef change is needed
for #134455 because otherwise frontends need to pass a TargetLowering
object to the helper functions just to know what the target-specific
limit is.
This also changes the LangRef for atomicrmw. Are there libatomic
fallbacks for these? If not, LLVM-IR validity still depends on
instantiating the actual backend. There are also some intrinsics such as
`llvm.memcpy.element.unordered.atomic` that have this constraint but do
not change in this PR.
This patch introduces a new Python-based benchmarking tool for Clang's Lifetime Safety analysis. This script automates the process of generating targeted C++ test cases, measuring the performance of the analysis, and determining its empirical computational complexity.
The tool helps track and validate the performance of the dataflow analysis, ensuring that future optimizations have a measurable impact and that the analysis scales efficiently.
Components:
* **Generate**: Creates pathological C++ test cases with specific patterns (pointer cycles and CFG merges) designed to stress-test the analysis.
* **Compile & Trace**: Compiles the generated code using `-ftime-trace`.
* **Analyze & Report**: Performs a curve-fit on the timing data to determine the empirical complexity ( **O(n<sup>k</sup>)**) and outputs a markdown report.
---
**Usage**:
<details>
<summary>ninja benchmark_lifetime_safety_analysis</summary>
[12/13] Running Lifetime Analysis performance benchmarks...
Benchmark files will be saved in: <BUILD_DIR_REDACTED>/tools/clang/test/Analysis/LifetimeSafety/benchmark_results
Running performance benchmarks...
--- Running Test: Cycle with N=10 ---
Total: 10.11 ms | Analysis: 2.70 ms
--- Running Test: Cycle with N=25 ---
Total: 61.51 ms | Analysis: 53.05 ms
--- Running Test: Cycle with N=50 ---
Total: 688.56 ms | Analysis: 677.32 ms
--- Running Test: Cycle with N=75 ---
Total: 3.09 s | Analysis: 3.07 s
--- Running Test: Cycle with N=100 ---
Total: 9.31 s | Analysis: 9.30 s
--- Running Test: Cycle with N=150 ---
Total: 44.92 s | Analysis: 44.91 s
--- Running Test: Merge with N=10 ---
Total: 8.54 ms | Analysis: 0.00 ms
--- Running Test: Merge with N=50 ---
Total: 38.79 ms | Analysis: 27.13 ms
--- Running Test: Merge with N=100 ---
Total: 219.45 ms | Analysis: 205.20 ms
--- Running Test: Merge with N=200 ---
Total: 1.67 s | Analysis: 1.65 s
--- Running Test: Merge with N=400 ---
Total: 12.57 s | Analysis: 12.55 s
--- Running Test: Merge with N=800 ---
Total: 100.48 s | Analysis: 100.43 s
Generating Markdown Report...
</details>
<details>
<summary>Sample Report: </summary>
# Lifetime Analysis Performance Report
> Generated on: 2025-07-08 14:18:52
---
## Test Case: Pointer Cycle in Loop
| N | Analysis Time | Total Clang Time |
|:----|--------------:|-----------------:|
| 10 | 2.70 ms | 10.11 ms |
| 25 | 53.05 ms | 61.51 ms |
| 50 | 677.32 ms | 688.56 ms |
| 75 | 3.07 s | 3.09 s |
| 100 | 9.30 s | 9.31 s |
| 150 | 44.91 s | 44.92 s |
**Complexity Analysis:**
- The performance for this case scales approx. as **O(n<sup>3.88</sup>)**.
- **95% Confidence interval for exponent:** `[3.86, 3.90]`.
---
## Test Case: CFG Merges
| N | Analysis Time | Total Clang Time |
|:----|--------------:|-----------------:|
| 10 | 0.00 ms | 8.54 ms |
| 50 | 27.13 ms | 38.79 ms |
| 100 | 205.20 ms | 219.45 ms |
| 200 | 1.65 s | 1.67 s |
| 400 | 12.55 s | 12.57 s |
| 800 | 100.43 s | 100.48 s |
**Complexity Analysis:**
- The performance for this case scales approx. as **O(n<sup>3.00</sup>)**.
- **95% Confidence interval for exponent:** `[2.99, 3.01]`.
---
</details>
This patch introduces the core dataflow analysis infrastructure for the C++ Lifetime Safety checker. This change implements the logic to propagate "loan" information across the control-flow graph. The primary goal is to compute a fixed-point state that accurately models which pointer (Origin) can hold which borrow (Loan) at any given program point.
Key components
* `LifetimeLattice`: Defines the dataflow state, mapping an `OriginID` to a `LoanSet` using `llvm::ImmutableMap`.
* `Transferer`: Implements the transfer function, which updates the `LifetimeLattice` by applying the lifetime facts (Issue, AssignOrigin, etc.) generated for each basic block.
* `LifetimeDataflow`: A forward dataflow analysis driver that uses a worklist algorithm to iterate over the CFG until the lattice state converges.
The existing test suite has been extended to check the final dataflow results.
This work is a prerequisite for the final step of the analysis: consuming these results to identify and report lifetime violations.
The previous test simply tried to double free the pointer in the
EXPECT_DEATH macro. Unfortunately, the gtest infrastructure can allocate
a pointer that happens to be the previously freed pointer. Thus the free
doesn't fail since the spawned process does not attempt to free all of
the pointers allocated in the original test.
NOTE: Scudo should be checked to make sure that the TSD is not always
returning pointers in the same order they are freed. Although this
appears to be a problem with a program that only does a small number of
allocations.
Rework derived type initialization in the runtime to just initialize the
first element of any array, and then memcpy it to the others, rather
than exercising the per-component paths for each element.
Reword derived type destruction in the runtime to detect and exploit a
fast path for allocatable components whose types themselves don't need
nested destruction.
Small tweaks were made in hot paths exposed by profiling in descriptor
operations and derived type assignment.
Interpret TRANSFER(SOURCE=BOZ literal, MOLD=integer or real scalar) as
if it had been a reference to the standard INT or REAL intrinsic
functions, for which a BOZ literal is an acceptable argument, with a
warning about non-conformance. It's a needless extension that has
somehow crept into some other compilers and real applications.
When blank tokens arise from macro replacement in token sequences with
token pasting (##), the preprocessor is producing some bogus tokens
(e.g., "name(") that can lead to subtle bugs later when macro names are
not recognized as such.
The fix is to not paste tokens together when the result would not be a
valid Fortran or C token in the preprocessing context.
This PR restructures the vocabulary.
* String based look-ups are removed. Vocabulary is changed from a map to vector. (#141832)
* Grouped all the vocabulary related methods under a single class - `ir2vec::Vocabulary`. This replaces `IR2VecVocabResult`.
* `ir2vec::Vocabulary` effectively abstracts out the _layout_ and other internal details of the vector structure. Exposes necessary APIs for accessing the Vocabulary.
These changes ensure that _all_ known opcodes and types are present in the vocabulary. We have retained the original operands. This can be extended going forward.
(Tracking issue - #141817)
The recipe body generation was moved from lowering into FIR's
implementation of MappableType API. And now since all Fortran variable
types implement this type, lowering of OpenACC was updated to use this
API directly. No test changes were needed - all of the private,
firstprivate, and recipe tests get the same body as before.
I spent several hours debugging failures in the server 2022 container
today that turned out to be related to a new ninja release from a couple
weeks ago. This patch version pins all the packages so they do not
spuriously upgrade and we can control the process to waste less effort
debugging changes due to version changes.
Reviewers: cmtice, tstellar, lnihlen
Reviewed By: cmtice
Pull Request: https://github.com/llvm/llvm-project/pull/148319
- when there are duplicate (equivalent) `RangeInfo`s created we will
attempt to `llvm::sort` or `llvm::stable_sort` them, it does not appear
deterministic in which order they will be sorted (because they are
equivalent)
- when `DLLVM_ENABLE_EXSTENSIVE_CHECKS` is enabled, it appears to deal
with this tie-breaker sorting the list differently than when it is not
enabled, this causes one of the test cases to fail because the
diagnostic is produced, not in a different order, but with a different
root element associated with an identical `RangeInfo`
- functionally this makes no difference to the diagnostic being produced
and the removed test-case was added just as a nicety to demonstrate how
the diagnostics might look
- the test above the removed will correctly demonstrate that the
`SourceLocation` will be set to the correct column, and, the `-verify`
portion of this testcase will ensure that we still generate a diagnostic
for each duplicate
- therefore, it is safe to remove this portion of the test-case that can
have a non-deterministic association of root element
This resolves the build issues reported
[here](https://github.com/llvm/llvm-project/pull/147115#issuecomment-3069543491)
and
[here](https://github.com/llvm/llvm-project/pull/147800#issuecomment-3069797406)
This patch upstreams support for writing inline and out of line C++
destructor definitions. Calling a destructor implcitly or explicitly is
left for a future patch.
Because of that restriction complete destructors (D2 in Itanium
mangling) do not call into the base (D1) destructors yet but simply
behave like a base destructor. Deleting (D0) destructor support is not
part of this patch.
Destructor aliases aren't supported, either. Because of this compilation
with -mno-constructor-aliases may be required to avoid running into NYI
errors.
[WebAssembly] Fold fadd contract (fmul contract) to relaxed madd w/
-mattr=+simd128,+relaxed-simd
Fixes#121311
- Precommit test for #121311
- Fold fadd contract (fmul contract) to relaxed madd w/
-mattr=+simd128,+relaxed-simd
- Move PatFrag of fadd_contract in ARM.td and WebAssembly.td to
TargetSelectionDAG.td for reuse of pattern
This patch allows optimizing redundant array repacking, when
the source array is statically known to be contiguous.
This is part of the implementation plan for the array repacking
feature, though, it does not affect any real life use case
as long as FIR inlining is not a thing. I experimented with
simple cases of FIR inling using `-inline-all`, and I recorded
these cases in optimize-array-repacking.fir tests.
We cannot attach any "data" or "descriptor" tag to accesses
of derived types that contain descriptors, because this
will make them non-aliasing with any generic "data" or "descriptor"
accesses, which is not correct. We have to skip TBAA tags attachment
for such accesses same way we do it for boxes.
In order to create temporary copies of assumed-type arrays
(e.g. for `-frepack-arrays`), we have to allow the source_box
to be a !fir.box.
This patch replaces #147618.
A hardware loop instruction combines a subtract, compare with zero, and
branch. We currently account for the compare and branch being combined
into one in Cost::RateFormula, as part of more general handling for
compare-branch-zero, but don't account for the subtract, leading to
suboptimal decisions in some cases.
Fix this in Cost::RateRegister by noticing when we have such a subtract
and discounting the AddRecCost in such a case.
This patch bumps the windows CI container to windows server 2022 from
windows server 2019. This is necessary as Github has sunsetted support
for sever 2019, so we cannot build the container through GHA without
updating. Using more recent versions is just good practice anyways.
This will not roll out immediately and we'll have to make some TF
changes to get deployed, but some additional validation first will be
good anyways.
Reviewers: lnihlen, tstellar, cmtice
Reviewed By: cmtice
Pull Request: https://github.com/llvm/llvm-project/pull/148318
This enables memref.load/store + vector.load/store support for sub-byte
float types. Since the memref types don't matter for loads/stores, we
still use the same types as integers with equivalent widths, with a few
extra bitcasts needed around certain operations.
There is no direct change needed for vector.load/store support. The
tests added for them are to verify that float types are
supported as well.
This is a hotfix for #148615 - it fixes the issue for me locally.
I think a broader issue is that in the test environment we're calling
olShutDown from a global destructor in the test binaries. We should do
something more controlled, either calling olInit/olShutDown in every
test, or move those to a GTest global environment. I didn't do that
originally because it looked like it needed changes to LLVM's GTest
wrapper.
Currently `builder.create<...>` does not in any meaningful way hint/show
the various builders an op supports (arg names/types) because [`create`
forwards the args to
`build`](887222e352/mlir/include/mlir/IR/Builders.h (L503)).
To improve QoL, this PR adds static create methods to the ops themselves
like
```c++
static arith::ConstantIntOp create(OpBuilder& builder, Location location, int64_t value, unsigned width);
```
Now if one types `arith::ConstantIntO::create(builder,...` instead of
`builder.create<arith::ConstantIntO>(...` auto-complete/hints will pop
up.
See
https://discourse.llvm.org/t/rfc-building-mlir-operation-observed-caveats-and-proposed-solution/87204/13
for more info.
In #125921, the changes requested by P2372R3 were completed and tested
together with corresponding `chrono` types. But that PR didn't mention
P2372R3. The `__cpp_lib_format` FTM was even bumped by an earlier PR
#98275.
This PR confirms that P2372R3 was completed in LLVM 21 (together with P1361R2).
Closes#100043
This patch contains fixes for various nits mentioned in #147200:
- This patch removes the `bit.` prefix in the op mnemonic. The operation
names now directly correspond to the builtin function names except for
`bswap` which is represented by `cir.byte_swap` for more clarity.
- Since all bit operations are `SameOperandsAndResultType`, this patch
updates their assembly format and avoids spelling out the operand type
twice.
Add `OffloadDeviceTest::getPlatformBackend()` and use it to skip event
tests which currently fail on AMDGPU due to:
```
OL_ERRC_UNIMPLEMENTED: synchronize event not implemented
```
