[mlir][llvm] Add more constrained FP operations (#213745)
This change adds special constrained forms of transcendental operations
for the remaining cases that lower to contrained fp intrinsic calls. It
also adds fast-math flag support to the constrained operations, which is
needed to handle combinations of Clang command-line options such as
"-ffinite-math-only -ftrapping-math".
Assisted-by: Cursor / various models
[CIR][AArch64] Update builtin handlers to use emitNeonCallToOp (#214075)
This is another change to prepare AArch64 builtin handling for the
transition to constrained FP handling. It replaces a number of places
where we were creating CIR operations directly with calls to
emitNeonCallToOp so that we will be able to centralize the constrained
FP handling.
This also updates the vrndns_f32 to eliminate a redundant load of the
operand, which is the only part of this change with a visible difference
in the output.
Assisted-by: Cursor / Grok 4.5
[mlir][llvm] Add operations for coroutine intrinsics (#214099)
This adds operations to the LLVM dialect to represent coroutine
intrinsics that were previously missing from the dialect. A few
coroutine operations were already in place. This change adds operations
for the remaining intrinsics that cab be generated by Clang. There are
some additional coroutine intrinsics defined in LLVM IR that aren't
covered, but I'm omitting those until they are needed.
We are in the process of implementing coroutine support in CIR, and
these are the operations we'll need for lowering to LLVM.
Assisted-by: Cursor / Grok 4.5
[lldb] Refactor RegisterTypeBuilder
This prepares it for emitting union types. Major changes:
* Entry function is now a dispatcher to builder functions for each type.
* Name mangling is standardised.
* The register name parameter is no longer needed and so was removed.
[lldb][AArch64] Use unique_ptr instead of statics in RegisterTypeDetector
Fixes #214264.
I used static variables for the created types, on the assumption
that only one detector would be used and that the host's
features would not change.
That is true for an lldb-server on a real Linux/FreeBSD system.
It is not true when we use the detector with core files. In the
same LLDB session you might load several files that came from
systems with different features.
The result was that the first detection sets up the static variables
and future detections do not update them. So subsequent core
files can have incorrect types.
(and in future if types vary per-process, we could have the same
issue in lldb-server)
[31 lines not shown]
[lldb] Make RegisterFlagsDetector into RegisterTypesDetector
In future it may be generating things other than flags. Functionality
is the same, but the interface changes to use RegisterType.
[lldb] Store all XML register types in a single string map
We are assuming that their ID's are unique, so there's no need to keep
separate maps. We can do basic type checking by checking the kind of
the type pointed to.
A few more methods were added to the base RegisterType. GetSize()
returns 0 for enums because enums don't have a size until they are
used by a register. This is not ideal but it works for now.
[AMDGPU] Set gfx13 LDS to 192KB and model LDS size via subtarget features
Set gfx13 addressable LDS to 192KB (96KB in CU mode).
Replace the isGFX10/1250 if-logic to calculate LDS size with FeatureLocalMemorySize.
This change is NFC for all targets except gfx13.
[CIR][MLIR-LLVM] Add 'thread local mode/model' attribute support (#214337)
The main purpose of this patch is to implement the 'tls_model' attribute
for ClangIR. However, this required updating the LLVM-IR dialect to ALSO
support this, not just as a bool. This patch threads it into both sides.
CIR tries to refer to it as "TLS_Model" to match the C/C++ attribute
closely, the LLVM Dialect refers to it as ThreadLocalMode to reflect
better what LLVM does.
Left as still 'not done' (in CIR only!) is the lowering of the 'other'
kinds of thread-local settings, which are intended to do various levels
of locking/initialization. Those are left for a future implementation
effort. The C++ test itself is taken directly from classic codegen.
[IVDescriptors] Implement MonotonicDescriptor
RFC link: https://discourse.llvm.org/t/rfc-loop-vectorization-of-compress-store-expand-load-patterns/86442
"Monotonic" variable is similar to induction variable, but its value is updated under some condition, e.g.:
```
int idx = 0;
for(int i = 0; i < n; ++i) {
// some uses of idx
if (cond)
++idx;
}
```
In this example, `i` is induction variable and `idx` is monotonic variable: it's updated only when cond == true. In LLVM IR, this looks like:
```
loop_header:
%monotonic_phi = [%start, %prehader], [ %chain_phi0, %latch]
step_bb:
[26 lines not shown]
[clang-tidy][docs] Rewrite bugprone check docs to Markdown [1/4] (#214413)
Tracking issue: #201242
See the [migration guide] for more information.
[migration guide]:
https://llvm.org/docs/SphinxQuickstartTemplate.html#markdown-migration-guidelines
This rewrites part 1/4 of the remaining bugprone check documentation
from reST to MyST Markdown.
AI Usage: This was prepared with rst2myst and GPT5.6-assisted cleanup.
I manually verified that the documentation renders as expected.
Preview site:
https://broken.life/llvm-staging/bugprone-markdown-port/
[clang-tidy][docs] Rename bugprone check docs to Markdown [1/4] (#214412)
Tracking issue: #201242
See the [migration guide] for more information.
[migration guide]:
https://llvm.org/docs/SphinxQuickstartTemplate.html#markdown-migration-guidelines
This is the mechanical rename for part 1/4 of the remaining `bugprone`
check documentation.
The rewrite is provided by the next PR in this stack.
[analyzer] Fix -analyzer-output=sarif crash on macro-expanded ranges
A path piece whose range ends inside a macro expansion aborted the whole
document: https://godbolt.org/z/61vWYcsWj
Cannot create a physicalLocation from invalid SourceRange!
convertTokenRangeToCharRange() built the end with
Lexer::getLocForEndOfToken(), which returns an invalid location for a macro
ID that is not at the end of its expansion, and used it unchecked. The
analyzer's own test corpus hits this in nine files; text and plist output
were unaffected because both already map such ranges to the expansion.
- Use getExpansionRangeInFile(), so the region covers the macro use like the
other two outputs.
- Fall back to a caret when the range is unusable. A thread flow needs a
location per piece, so dropping one would truncate the reported path. This
also stops reversed ranges producing regions with endColumn < startColumn.
[4 lines not shown]
[analyzer] Fix -analyzer-output=html assert on reversed and macro ranges
HTMLDiagnostics::HighlightRange guarded against a reversed range by
comparing line numbers, so a same-line reversal - which is what the piece for
an implicit copy constructor carries - reached html::HighlightRange.
Its scan walks from begin to end, ran off the end of the buffer, and asserted:
https://godbolt.org/z/sTb5qfjjd
Invalid position to insert! (RewriteRope.h)
It also added the end token's length itself and then passed a token range to
html::HighlightRange, which measured the token again, this time from the
interior. For most tokens the two cancel, but where the tail re-lexes longer
the highlight reached past the end of the range, e.g. over a trailing ';'.
Use getExpansionRangeInFile(), which rejects reversed and cross-file ranges,
then convert once and tell html::HighlightRange the range is already
char-granular.
[4 lines not shown]
[clang] Reject ranges getExpansionRangeInFile cannot represent
getExpansionRangeInFile was extracted verbatim and inherited two shortcomings
of the original loop, fixed here before the analyzer's SARIF and HTML consumers
depend on it:
- It mapped the end with getExpansionRange(SourceLocation), which always
reports a token range, so a char-range input was widened by a whole token.
Now using the getExpansionRange(CharSourceRange) overload, which keeps the flag.
- It passed reversed ranges through. Consumers walk begin->end; now returning
nullopt for those, as Lexer::makeFileCharRange already does.
Separate from the extraction so that stays NFC, and out of the consumer fixes
because it changes the shared helper's contract rather than one output.
Both contract changes, plus the invalid- and cross-file-range guards, are
covered by a GetExpansionRangeInFile unit test in
clang/unittests/Frontend/TextDiagnosticTest.cpp.
Assisted-By: claude
[clang][NFC] Extract getExpansionRangeInFile out of the diagnostic renderers
Prep for the following commits, which fix crashes in the analyzer's SARIF and
HTML output on ranges that end inside a macro expansion. Fixing them means
mapping such a range into the reported file - the normalization the frontend
text and SARIF renderers already do, and that the two analyzer consumers each
do differently and incorrectly.
Hoist that logic into getExpansionRangeInFile, beside the DiagnosticRenderer
base both frontend renderers derive from, so the fixes reuse one
implementation instead of adding two more copies. TextDiagnostic and
SARIFDiagnostic move onto it here with no behavior change; the analyzer
consumers follow in later commits.
getFileID() replaces SARIFDiagnostic's getDecomposedLoc(...).first - equivalent
here, and what TextDiagnostic has used since c113cbb51005.
Assisted-By: claude
[AArch64][CostModel] Consider some nxv1 operations as legal
This is allowing some operations on vscale x 1 types, namely:
- load/store
- masked load/store
- arithmetic instructions like add/sub/mul
For those, there is already codegen coverage. See e.g.
- llvm/test/CodeGen/AArch64/sve-int-arith.ll
- llvm/test/CodeGen/AArch64/sve-load-store-legalisation.ll
- llvm/test/CodeGen/AArch64/sve-masked-gather.ll
- llvm/test/CodeGen/AArch64/sve-masked-scatter.ll
