[mlir][spirv] Add first 7 elementwise unary ops in TOSA Ext Inst Set (#185885)
This patch introduces the following elementwise unary operators:
spirv.Tosa.Abs
spirv.Tosa.BitwiseNot
spirv.Tosa.Ceil
spirv.Tosa.Clz
spirv.Tosa.Cos
spirv.Tosa.Exp
spirv.Tosa.Floor
Also dialect and serialization round-trip tests have been added.
Signed-off-by: Davide Grohmann <davide.grohmann at arm.com>
[libc] Implement iswgraph entrypoint (#185339)
part of https://github.com/llvm/llvm-project/issues/185136;
This PR adds public entrypoints for the wide character classification
function iswgraph in LLVM libc, using the same pattern as the existing
iswalpha entrypoint.
using bellow cmd to test:
```shell
ninja libc.test.src.wctype.iswgraph_test.__unit__
```
[MIR] Support symbolic inline asm operands
Support parsing and printing inline assembly operands in MIR
using the symbolic form instead of numeric register class IDs,
thus removing the need to update tests when the numbers change.
The numeric form remains supported.
Co-Authored-By: Claude Opus 4.6 <noreply at anthropic.com>
[clang][lit] Fix spirv-tools-err.c when LIT_USE_INTERNAL_SHELL=0 (#185876)
Only the internal shell parser is able to process an operator in the
middle of a command. For the other shells, the operator must appear in
the beginning of the line.
[SPIRV] fix `alloca` -> `OpVariable` lowering (#164175)
fixes #163777
Test was written with help from Copilot
---------
Co-authored-by: Juan Manuel Martinez Caamaño <jmartinezcaamao at gmail.com>
[libc] Fix detection of cfloat128 (#185486)
Building compiler-rt with aarch64-buildroot-linux-gnu-gcc 15.2 causes a
build error:
```
compiler-rt-22.1.0/cmake/Modules/../../libc/src/__support/CPP/type_traits/is_complex.h:44:31:
error: 'cfloat128' was not declared in this scope; did you mean 'float128'? [-Wtemplate-body]
```
According to
https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Floating-Types.html
__float128 is not available on aarch64.
Analyzing the gcc defines for aarch64 seems to prove it:
```
$ aarch64-buildroot-linux-gnu-gcc -v
Target: aarch64-buildroot-linux-gnu
gcc version 15.2.0 (Buildroot 2026.02-114-gdadec9da56)
$ echo | aarch64-buildroot-linux-gnu-gcc -dM -E - | grep __GCC_IEC_559_COMPLEX
[26 lines not shown]
[clang][modules] Unlock before reading just-built PCM (#183787)
Implicitly-built modules are stored in the in-memory cache of the
`CompilerInstance` responsible for building it. This means it's safe to
release the lock right after building it, and read it outside of the
critical section from the in-memory module cache. This speeds up
dependency scanning in a statistically significant way, somewhere
between 0.5% and 1.0%.
[NFC][analyzer] Clarify current LocationContext and CFGBlock (#185107)
The analyzer often uses the current `LocationContext` and `CFGBlock`,
for example to assign unique identifiers to conjured symbols.
This information is currently handled in a haphazard way:
- Logic that determines this is often duplicated in several redundant
locations.
- It is stored in `NodeBuilderContext` objects, despite the fact that it
is not actually used for building (exploded) nodes.
- Many methods pass it around in arguments, while many others use it
through the field `NodeBuilderContext *currBldrCtx` of `ExprEngine`.
- This `currBldrCtx` points to local variables in random stack frames,
e.g. there is an early return in `ExprEngine::processBranch` where it
becomes stale (but AFAIK it is never dereferenced after that point).
This commit starts a transition to a more principled system, where there
is a single canonical source for accessing this information (methods of
`ExprEngine`), which is populated once per `dispatchWorkItem` call, as
[8 lines not shown]
[ARM] Use FPRegs for fastcc calling convention detection. (#184593)
This was using VFP2, but nowadays should use hasFPRegs to detect the
effective calling convention.
Fixes #109922.
[clang][dataflow] Add basic modeling for compound assignments. (#179058)
Do our best to assign a value to the left-hand-side storage. Do not
model the actual arithmetic operation yet; the value is going to be
unknown in case of compound assignments. But either way, simularly to
#178943,we need to at least make sure that the old value does not stick
around. And it's better to conjure a fresh value than to leave it
completely unmodeled because subsequent loads from that location need to
produce consistent results.
Additionally make sure that the storage location is correctly propagated
in regular assignments too, even if we couldn't produce a fresh value at
all.
---------
Co-authored-by: Yitzhak Mandelbaum <ymand at users.noreply.github.com>
[MLIR] Update DIDerivedType To Support File, Line And Scope (#185665)
This PR updates `DIDerivedTypeAttr` to support optional file, line and
scope parameters in the same way as `DICompositeTypeAttr`. These
parameters are already supported in the `llvm::DIDerivedType`
constructor and were hardcoded to nullptr/0, they are now accessible
from MLIR.
The existing `llvmir-debug.mlir` test has been updated to test these
changes.
[clang][SPIRV] Coerce pointer kernel arguments to global AS (#185498)
SPIR-V does not allow pointer kernel arguments to be in the generic
address space. For offload, we already coerece them to the global
address space if not specified.
We are seeing that we need to do the same for SPIR-V directly as some of
the liboffload unit tests are compiled for `spirv64` directly, otherwise
we produce invalid SPIR-V.
---------
Signed-off-by: Nick Sarnie <nick.sarnie at intel.com>
[clang-tidy][NFC] Don't qualify names unless strictly necessary (#185169)
We have a de-facto policy in clang-tidy to not qualify names unless
absolutely necessary. We're *mostly* consistent about that (especially
in new code), but a number of deviations have accumulated over the
years. We even have cases where the same name is sometimes qualified and
sometimes not *in the same file*. This makes it jarring to read the
code, and, I imagine, more confusing for newcomers to contribute to the
project (do I qualify X or not?). This PR tries to improve the situation
and regularize the codebase.
[SPIR-V] Fix lowering of declarations with hidden visibility (#185029)
They should be translated to SPIR-V and have Import linkage (unless they
are Interface variables).
Also add a test for protected visibility, just to make sure, that we are
aligned it its translation.
[LAA] Fix type mismatch in getStartAndEndForAccess. (#183116)
`SE.getUMaxExpr` causes assertion failure due to type mismatch here:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Analysis/LoopAccessAnalysis.cpp#L253
Running `opt -S -p loop-vectorize -debug-only=loop-vectorize
llvm/test/Analysis/LoopAccessAnalysis/type-mismatch-in-scalar-evolution.ll
` without the changes made in LoopAccessAnalysis.cpp causes assertion
failure.
Attaching the stack dump for reference:
```
LV: Checking a loop in 'loop_contains_store_assumed_bounds' from input.ll
LV: Loop hints: force=? width=4 interleave=0
LV: Found a loop: for.body
LV: Found an induction variable.
opt: /home/kshitij/llvm-project/llvm/lib/Analysis/ScalarEvolution.cpp:3918: const llvm::SCEV* llvm::ScalarEvolution::getMinMaxExpr(llvm::SCEVTypes, llvm::SmallVectorImpl<const llvm::SCEV*>&): Assertion `getEffectiveSCEVType(Ops[i]->getType()) == ETy && "Operand types don't match!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace and instructions to reproduce the bug.
[41 lines not shown]
[AArch64] fuse constant addition after sbb (#185117)
Resolves: #171676
Related: #184541 (x86_64 PR)
The issue points out that `Fold ADD(ADC(Y,0,W),X) -> ADC(X,Y,W)` is
optimized and that SBB can be optimized similarly:
`Fold ADD(SBB(Y,0,W),C) -> SBB(Y,-C,W)`.
With the changes from this branch, a new clang will compile the example
code:
```
#include <stdint.h>
uint64_t f(uint64_t a, uint64_t b) {
uint64_t x;
x += __builtin_add_overflow(a, b, &x);
return x + 10;
[22 lines not shown]
libclc: Update ilogb implementation
This was originally ported from rocm device libs in
d6d0454231ac489c50465d608ddf3f5d900e1535. Update for
more recent changes that were made there. This avoids
bithacking and improves value tracking. This also allows
using a common code path for all types.
