I noticed that the various `_LIBCPP_INTRODUCED_IN_LLVM_<ver>` usages in
`availability.h` were defined a bit all over the place. I think it'd
make the most sense to sort them in reverse chronological order (like
their definitions).
`GetSyntheticValue` in synthetic providers which need to operate on raw
root values, but will often want to use the synthetic value of children,
or nested children.
The current implementation of `!DIR IVDEP` leads flang to bypass LLVM
cost model and always vectorize the loop carrying `!DIR$ IVDEP`.
IVDEP is an extension and its documentation varies, and while it usually
leads to vectorization because it is added on loops where it is usually
profitable, its documentation only tells it is meant to tell the
compiler that there are no loop carried dependencies and that the loop
is safe to vectorize.
In some application, such directive may have been added to help the
compiler proving it is safe to vectorize, but vectorizing is not always
the best choice for all architectures. The cost model should still be
applied. This is at least the case for classic flang.
When users want vectorization to happen, they should use `!DIR$ VECTOR
ALWAYS`.
This patch updates flang to not emit `llvm.loop.vectorize.enable` just
because IVDEP was seen. Instead, IVDEP now only controls the emissions
of the access groups to translate the independence of the accesses and
leave the vectorization decision up to the cost model. `!DIR$ VECTOR
ALWAYS` can be used in combination with IVDEP to force vectorization (it
causes the emission of `llvm.loop.vectorize.enable`).
The time in flang/docs/GettingInvolved.md says 8:00 a.m. Pacific, but
the scheduled meeting occurs at 7:30 a.m. Pacific. A link to the LLVM
community calendar was also added to both this and the entry for the
main biweekly flang call since it is not clear when the calls actually
happen.
This PR converts the syntax highlighters to plugins. Previously, the
highlighters were part of the Language plugin, using a library shared by
the C-like languages. The Highlighters already had a plugin-like design,
with a clang and default highlighter. This PR takes them out of the
language plugin and into their own highlighter plugin. They are still
accessed thought he HighlightManager.
This change is motivated by #170250. It will allow us to have both a
clang and tree-sitter based highlighter, as well as make it possible to
have a highlighter for a language that doesn't have an upstream language
plugin, like Swift or Rust.
As usual, this is one of our most expensive checks according to
`--enable-check-profile`.
Measuring overall runtime:
```sh
hyperfine \
--shell=none \
--prepare='cmake --build build/release --target clang-tidy' \
'./build/release/bin/clang-tidy --checks=-*,readability-uppercase-literal-suffix all_headers.cpp -header-filter=.* -system-headers -- -std=c++23 -fno-delayed-template-parsing'
```
Status quo:
```txt
Time (mean ± σ): 4.435 s ± 0.012 s [User: 4.158 s, System: 0.275 s]
Range (min … max): 4.409 s … 4.455 s 10 runs
```
With this change:
```txt
Time (mean ± σ): 3.549 s ± 0.010 s [User: 3.328 s, System: 0.223 s]
Range (min … max): 3.540 s … 3.569 s 10 runs
```
Measuring with `--enable-check-profile`:
Status quo:
```txt
---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---
1.1875 (100.0%) 0.1406 (100.0%) 1.3281 (100.0%) 1.3147 (100.0%) readability-uppercase-literal-suffix
```
With this change:
```txt
---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---
0.2500 (100.0%) 0.0469 (100.0%) 0.2969 (100.0%) 0.2904 (100.0%) readability-uppercase-literal-suffix
```
However, subtracting 200 ms to account for the "[`hasParent`
tax](https://github.com/llvm/llvm-project/pull/178149#discussion_r2736652174)",
the "true" numbers are probably closer to:
```
---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---
Status quo: 0.9875 (100.0%) 0.1406 (100.0%) 1.1281 (100.0%) 1.1147 (100.0%) readability-uppercase-literal-suffix
With this change: 0.0500 (100.0%) 0.0469 (100.0%) 0.0969 (100.0%) 0.0904 (100.0%) readability-uppercase-literal-suffix
In a typical build, the build system schedules many TUs from the same
target to be scanned/compiled at the same time. These TUs tend to depend
on a similar set of modules, and they usually keep their imports
alphabetically sorted. The nature of implicit modules then means that
scanning these TUs reduces into a single-threaded computation, since
only one TU wins the race to compile the common dependency module, and
the same thread/process keeps being responsible for compiling all
transitive dependencies of such module.
This PR makes use of the single-module-parse-mode in a new scanning step
that runs at the start of each TU scan. In this step, the scanner
quickly discovers unconditional module dependencies of the TU without
blocking on its compile. This typically discovers plenty of work to keep
the available threads busy and compile modules in more parallel fashion.
Modules discovered here are compiled on separate threads right away in
the same two-step fashion.
The second step then performs the regular dependency scan of the TU
where each module import is a blocking operation. However, by this time,
the first scanning step most likely already compiled the majority of
modules, so there's actually little to no waiting happening here. The
compiler only deserializes previously-built modules.
This is a barebones implementation with some known quirks marked in
FIXME comments. I will continue working on performance and polish once
this lands.
Currently, when calling `.load(register=False)`, `op._attach_traits()`
isn’t executed. This PR ensures traits are attached regardless of
whether `register` is `True` or `False`.
`DenseElementsAttr::get(ShapedType, ArrayRef<Attribute>)` crashed with an unconditional `cast<IntegerAttr>` when encountering attribute types that are neither `FloatAttr` nor `IntegerAttr` (e.g. `ub.poison`). This can happen when folding ops like `tensor.from_elements` whose operands include poison values.
This patch fixes the issue at the `DenseElementsAttr::get` level rather than in individual op folders. The `cast<IntegerAttr>` is replaced with `dyn_cast<IntegerAttr>`, and when the attribute is neither `FloatAttr` nor `IntegerAttr`, a null `DenseElementsAttr` is returned. This is a more robust fix because it prevents the same class of crashes in any caller that passes unsupported attributes to `DenseElementsAttr::get`.
Fixes#178209.
---------
Co-authored-by: rebel-jueonpark <jueonpark@rebellions.ai>
This fixes the regressions after merging #174566
The problem was, that the lookup of the location takes logarithmic time
as a function of the number of lines, and a large number of lines causes
the slowdowns. Now all the lookups are guarded with checks if the
AsmParserContext was passed in, to not waste time on information, that
isn't requested.
Add a new helper function `matchEquivZeroRHS()` that recognizes
comparisons with constants that are equivalent to comparisons with zero,
and transforms the predicate accordingly.
This handles the following transformations:
- icmp sgt X, -1 --> icmp sge X, 0
- icmp sle X, -1 --> icmp slt X, 0
- icmp [us]ge X, 1 --> icmp [us]gt X, 0
- icmp [us]lt X, 1 --> icmp [us]le X, 0
This enables more optimization opportunities in `simplifyICmpWithZero`,
such as folding icmp sgt X, -1 when X is known to be non-negative.
---
- IR Impact: https://github.com/dtcxzyw/llvm-opt-benchmark/pull/3414
Updated RUN lines and generated new `CHECK‑SME`/`CHECK‑SVE` lines in:
llvm/test/CodeGen/AArch64/arm64-cvt-simd-fptoi.ll
llvm/test/CodeGen/AArch64/arm64-cvtf-simd-itofp.ll
by adding `-force-streaming` and `-force-streaming-compatible` runs,
as pre-commit tests for change #177334 to enable FPRCVT streaming.
This triggers a SVE scalar-combine path which requires a code update.
FP_TO_*_SAT nodes require operand 1 (the saturation VT) to be present.
Without it the node is malformed and hits the SelectionDAG assertion
“Invalid child # of SDNode!”.
See also #177334
As of recently, in LLDB, when trying to mutate an object in a const
method, we emit a hint about why we failed to run the expression (with
an associated hint on how to fix it). This relies on the diagnostic ID
that Clang told us about. However, we only want to emit this message
when we assign to a member in a const method. But not all the other
situations that `err_typecheck_assign` gets used in. We currently work
around this by grepping the error message, but it would be nice if we
could just rely on the diagnostic ID.
This patch splits out the relevant diagnostic.
This isn't urgent and we can live with the "grep the error message"
approach. But if the Clang maintainers don't feel strongly about keeping
the tablegen as-is, it'd be nice to clean up from LLDB's perspective.
The Armv9.6-A compare-and-branch instructions use a short range 9-bit
immediate value. They do not have a corresponding relocation type in the
ABI. For now we only support them in compact code model, with
diagnostics added in the LongJmp pass to ensure this condition. Some
interesting edge cases we cover:
- function splitting works when target is within or beyond the 1KB range
of those instructions,
- but doesn't work beyond the 128MB limit of the compact code model
- branch inversion works with block reordering so long as the immediate
value adjustments remain in bounds
This patch adds synchronization scope support to the `cir.atomic.fetch`
operation.
Most of the new test code in `atomic-scoped.c` is generated by an AI
agent. The generated tests are manually reviewed and verified.
Assisted-by: Copilot with GPT-5.2-Codex
Summary:
This change allows lambdas to be used in the RPC dispatching functions.
Just requires an extra function trait to convert a lambda with no
captures into a function pointer. Also rearranged where the `Port` lives
because it looks better no that we may use a lambda and it's more
consistent with the dispatch usage (putting the client at the start).
For the Ada compiler, it is sometimes useful to emit an anonymous basic
type. Currently, this is prohibited by DIBuilder, but there doesn't seem
to be a deep reason for this prohibition -- DWARF allows anonymous base
types, and the LLVM DWARF writer also accounts for this possibility.
A result of various cleanups, reimplementations/etc, I ended up with a
return after an if/else branch where each returned in #168422.
This patch removes the 'else' after a return, and removes the
unreachable return.
We reassociate ((x && y) && z) -> (x && (y && z)) if x has more than
use, in order to allow simplifying the header mask further. However this
is somewhat unreliable as there are times when it doesn't have more than
one use, e.g. see the case we run into in
https://github.com/llvm/llvm-project/pull/173265/changes#r2769759907.
This moves it into a separate transformation that always reassociates
the header mask regardless of the number of uses, which prevents some
fragile test changes in #173265.
We need to run it before both calls to simplifyRecipes in optimize. I
considered putting it in simplifyRecipes itself but simplifyRecipes is
also called after unrolling and when the loop region is dissolved which
causes vputils::findHeaderMask to assert.
There isn't really any benefit to reassociating masks that aren't the
header mask so the existing simplification was removed.
Don't pass a combination of `-std=c++26` and `-fcxx-exceptions` to tests
and then try to use `throw` as an invalid statement. C++26 actually has
working exceptions at compile time, even if that is currently not
implemented.
When the checker `readability-simplify-boolean-expr` is used on C23
code, where the `bool` type is provided but not `static_cast`, the fixer
suggests faulty code.
```
bool negative_condition_conditional_return_statement(int i) {
if (!(i == 0)) return false; else return true;
}
/xx/llvm-project/build/../clang-tools-extra/test/clang-tidy/checkers/readability/simplify-boolean-expr-c23.c:323:25: warning: redundant boolean literal in conditional return statement [readability-simplify-boolean-expr]
323 | if (!(i == 0)) return false; else return true;
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
| return static_cast<bool>(i == 0)
```
Let's skip the use of `static_cast` for C code where a cast is not
needed.
---------
Signed-off-by: Björn Svensson <bjorn.a.svensson@est.tech>
At the moment all code in LLVM seems to explicitly assume that the
masked parameter passed to vector math functions always lives at the end
of the parameter list. See VFShape::get as an example. It seems odd then
for getParamIndexForOptionalMask to walk the parameter list looking for
the mask. Indeed, the loop vectoriser would break if the mask was passed
in any other argument position. For example, if the masked parameter
position was 1 for a vector version of powf it would end up over-writing
the exponent.
Provides the infrastructure for implementing and late-binding
OpInterfaces from Python.
* On the mlir-c API declaration side, each `XOpInterface` has a callback
struct, with a callback for each method and a userdata member (provided
as an arg to each method), and a
`mlirXOpInterfaceAttachFallbackModel(ctx, op_name, callbacks)` func.
* This CAPI is implemented by defining a subclass of
`XOpInterface::FallbackModel` that holds the callback struct and has
each method call the corresponding callback (with userdata as an arg).
Given a callback struct, a new `FallbackModel` is created and attached,
i.e. late bound, to the named op. (MLIR's interface infrastructure is
such that the thus registered `FallbackModel` will be returned in case
the op gets cast to the `XOpInterface`.)
* On the Python side, we expose a stand-in `XOpInterface` base class
which has one (class)method: `XOpInterface.attach(cls, op_name, ctx)`.
Python users subclass this class (`class MyInterfaceImpl(XOpInterface):
...`) and implement the interface's methods (with the right names and
signatures). The user calls `attach` on the subclass
(`MyInterfaceImpl.attach("my_dialect.my_op", ctx)`) which prepares the
callbacks struct _with userdata set to the subclass_ (as we use it to
lookup methods). These callbacks (and userdata) are then registered as
an `XOpInterface::FallbackModel` by
`mlirXOpInterfaceAttachFallbackModel(...)`. From then on the Python
methods will be used to respond to calls to the interface methods
(originating in C++).
This PR enables implementing the TransformOpInterface and the
MemoryEffectsOpInterface, both of which are required for making an op
into a transform op.
Everything besides the above linked code is there to facilitate exposing
the interfaces: the right types for the arguments of the methods are
exposed as are functions/methods for manipulating these arguments (e.g.
specifying side effects on `OpOperand`s and `OpResult`s and being able
to access and set the transform handles associated with args and
results).
Add a new VPlan subdirectory as common place for tests checking VPlan
printing. It contains a lit.local.cfg that only runs the tests when
assertions are enabled.
This removes the need to add explicit REQUIRES: asserts to VPlan tests.
PR: https://github.com/llvm/llvm-project/pull/180611
For now, production instances of LNT don't accept strings longer than
256 characters: they crash above that. In order to unblock uploading
results to LNT as soon as possible, disable that information for now.
Note that the commit SHA is still included in the run information, so
it is still possible to correlate orders back to their commit.
The `ASSERT_DEBUG_DEATH` in `MemoryTest` would occasionally crash on
macOS CI with following stacktrace:
```
06:53:31 Death test: { read_results = process_sp->ReadMemoryRanges(ranges, buffer); }
06:53:31 Result: died but not with expected error.
06:53:31 Expected: contains regular expression "read more than requested bytes"
06:53:31 Actual msg:
06:53:31 [ DEATH ] Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
06:53:31 [ DEATH ] 0 TargetTests 0x000000010055bb80 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56
06:53:31 [ DEATH ] 1 TargetTests 0x0000000100559778 llvm::sys::RunSignalHandlers() + 64
06:53:31 [ DEATH ] 2 TargetTests 0x000000010055c668 SignalHandler(int, __siginfo*, void*) + 344
06:53:31 [ DEATH ] 3 libsystem_platform.dylib 0x0000000196993744 _sigtramp + 56
06:53:31 [ DEATH ] 4 libsystem_trace.dylib 0x00000001966b5180 _os_log_preferences_refresh + 36
06:53:31 [ DEATH ] 5 libsystem_trace.dylib 0x00000001966b5740 os_signpost_enabled + 300
06:53:31 [ DEATH ] 6 TargetTests 0x0000000100500930 llvm::SignpostEmitter::startInterval(void const*, llvm::StringRef) + 68
06:53:31 [ DEATH ] 7 TargetTests 0x0000000100782c24 lldb_private::Timer::Timer(lldb_private::Timer::Category&, char const*, ...) + 168
06:53:31 [ DEATH ] 8 TargetTests 0x000000010069cd44 lldb_private::Process::ReadMemoryFromInferior(unsigned long long, void*, unsigned long, lldb_private::Status&) + 100
06:53:31 [ DEATH ] 9 TargetTests 0x000000010069cf68 lldb_private::Process::ReadMemoryRanges(llvm::ArrayRef<lldb_private::Range<unsigned long long, unsigned long>>, llvm::MutableArrayRef<unsigned char>) + 300
06:53:31 [ DEATH ] 10 TargetTests 0x000000010045482c MemoryDeathTest_TestReadMemoryRangesReturnsTooMuch_Test::TestBody() + 1748
```
By default, Google death-tests execute the code under test in a
sub-process (e.g., via `fork`, see [official
docs](https://google.github.io/googletest/reference/assertions.html#death)).
However, the os_log APIs are not safe across forks, and using the os_log
handles of a parent process is not guaranteed to work (read undefined).
This is why we sometimes non-deterministically crash.
On Darwin we compile with signposts enabled, and there's no mechanism of
avoiding calling into os_log once you've compiled with them enabled
(e.g., in our case we just check the runtime `os_signpost_enabled`). And
we seemingly seem to call into the signpost infrastructure from
arbitrary points in LLDB (wherever we use `Timer`s for example).
GoogleTest provides an alternative mechanism to spawn the death tests.
It "re-executes the unit binary but only runs the death tests". This
should avoid sharing the os_log handles with the parent. This mode is
called "threadsafe".
This patch sets this style for the only 2 death-tests currently in the
LLDB test-suite.
Since this is quite the foot-gun we should disable it for the entire
LLDB unit-test suite (or rethink the way we set up the signposts for
tests/llvm/etc.). But to make CI less flakey for now, do this for only
the tests in question.
This test was failing locally for me because I command script import
statements in my `~/.lldibinit` which print to `stdout`. E.g.,:
```
Traceback (most recent call last):
File "/Users/michaelbuch/Git/llvm-worktrees/main/lldb/test/API/driver/batch_mode/TestBatchMode.py", line 33, in test_batch_mode_no_commands_quits
self.assertEqual(proc.stdout, "")
AssertionError: 'The "bt" python commands have been instal[326 chars]p.\n' != ''
- The "bt" python commands have been installed and are ready for use.
- The "sd" python command has been installed and is ready for use.
- The "expr" python aliases have been installed and are ready for use.
- "malloc_info", "ptr_refs", "cstr_refs", "find_variable", and "objc_refs" commands have been installed, use the "--help" options on these commands for detailed help.
```
I guess we could have a separate test for `--batch` with a test-local
`.lldibinit` that confirms we actually load the lldbinit before
quitting. Not sure how much value that would be. For now I just added
the `--no-lldbinit` to the test
