LLVM/project b6a9f2f.github/workflows release-tasks.yml

workflows/release-task: Stop uploading lit to test.pypi.org (#214979)

The gh-action-pypi-publish action only supports being run once per job.
Running it twice results in the second upload always failing. Rather
than trying to create a complicated job structure to support uploading
to test.pypi.org and pypi.org, we just remove the test.pypi.org upload
for now.
DeltaFile
+0-6.github/workflows/release-tasks.yml
+0-61 files

LLVM/project ef4d4d0.github/workflows release-tasks.yml

release-tasks: Disable lit publishing for release candidates (#214972)

There is no rc in the lit version string, so release candidates get
published using the non-rc version number.
DeltaFile
+1-0.github/workflows/release-tasks.yml
+1-01 files

LLVM/project c405fd3mlir/lib/Dialect/OpenACC/Transforms ACCImplicitData.cpp, mlir/test/Dialect/OpenACC acc-implicit-data.mlir

[mlir][acc] Fold present() clauses on device values (#212815)

The compiler must emit acc.device_ptr mapping for device values,
however, an existing present clause prevents that. A present on a device
value always holds, so fold it away to allow implicit data handling to
generate device_ptr mapping.
DeltaFile
+56-20mlir/lib/Dialect/OpenACC/Transforms/ACCImplicitData.cpp
+46-0mlir/test/Dialect/OpenACC/acc-implicit-data.mlir
+102-202 files

LLVM/project 786ed0dclang/lib/Driver SanitizerArgs.cpp, clang/lib/Driver/ToolChains Hexagon.cpp

[Hexagon] Fix unusable SCS reg, make it selectable (#213820)

SCS hardcoded r19 as the shadow call stack pointer and required
-ffixed-r19. That was the wrong register to pick: r19 is precisely the
one the intended consumers cannot give up, so the feature was unusable
in practice.

* The Hexagon Linux kernel already reserves r19 for its thread-info
pointer (arch/hexagon/Makefile: "TIR_NAME := r19", documented there as
not configurable because it is hard-coded in several files).

* hexagon-hypervisor reserves r20-r28 (kernel/CMakeLists.txt), with r28
bound to a register global (H2K_gp).

That leaves h2 only r16-r19, so no single hardcoded choice can serve
both consumers.

Intersecting that with the callee-saved regs leaves r1{6,7,8}. So the
new default is r18.

    [5 lines not shown]
DeltaFile
+118-55llvm/test/CodeGen/Hexagon/shadow-call-stack.ll
+53-23llvm/lib/Target/Hexagon/HexagonFrameLowering.cpp
+53-6clang/test/Driver/fsanitize-shadow-call-stack-hexagon.c
+52-5clang/lib/Driver/SanitizerArgs.cpp
+19-0llvm/lib/Target/Hexagon/HexagonSubtarget.cpp
+17-0clang/lib/Driver/ToolChains/Hexagon.cpp
+312-896 files not shown
+364-9612 files

LLVM/project e46fe87llvm/lib/Target/AMDGPU AMDGPURegBankLegalizeRules.cpp, llvm/test/CodeGen/AMDGPU/GlobalISel load-zero-and-sign-extending-uniform.ll load-zero-and-sign-extending-uniform-in-vgpr.ll

AMDGPU/GlobalISel: RegBankLegalize rules for uniform i16 extending loads

Extending loads, i8 to i16, are legal on targets with true16.
Note: there is potentially a missing rule for uniform P4 when target
usesTrue16 and hasSMRDSmall but MMO does not satisfy isUL. Wasn't able
to construct an LLVM-IR test for this case, leaving it unsupported.
DeltaFile
+122-0llvm/test/CodeGen/AMDGPU/GlobalISel/load-zero-and-sign-extending-uniform-in-vgpr.ll
+116-0llvm/test/CodeGen/AMDGPU/GlobalISel/load-zero-and-sign-extending-uniform.ll
+6-0llvm/lib/Target/AMDGPU/AMDGPURegBankLegalizeRules.cpp
+244-03 files

LLVM/project 9d3e53alibcxx/utils/ci run-buildbot, libcxx/utils/ci/lnt README.md common.py

[libc++] Add tools for gathering historical benchmark data (#212775)

Benchmarking every commit of libc++ is prohibitively expensive: a single
run of the benchmark suite takes hours, and the data has to be
regenerated from scratch whenever the compiler, the OS or the benchmark
machines change. These tools instead sample the history at a coarse
granularity and drive libcxx-benchmark-commit.yml to fill in what is
missing.

Three tools cooperate, meant to be run periodically:

  select-anchor-commits  picks one commit per calendar bucket from Git
  plan-benchmarks        diffs that against what LNT already holds
  dispatch-benchmarks    requests the corresponding workflow runs

They keep no state of their own. They recompute the current and target
states from LNT and the GitHub Actions API, which allows running them in
a CRON. The dispatching of workflows is done using a budget, to avoid
launching tens of jobs and competing with other uses of the CI

    [3 lines not shown]
DeltaFile
+408-0libcxx/utils/ci/lnt/dispatch-benchmarks
+217-0libcxx/utils/ci/lnt/select-anchor-commits
+211-0libcxx/utils/ci/lnt/plan-benchmarks
+120-0libcxx/utils/ci/lnt/common.py
+64-18libcxx/utils/ci/lnt/README.md
+13-0libcxx/utils/ci/run-buildbot
+1,033-182 files not shown
+1,036-188 files

LLVM/project ad36a6bclang/lib/CodeGen CGObjCGNU.cpp, clang/test/CodeGenObjC exceptions-personality.m

Fix CGObjCGNU __cxa_rethrow return type (#214496)

PtrTy -> VoidTy
DeltaFile
+2-2clang/lib/CodeGen/CGObjCGNU.cpp
+3-1clang/test/CodeGenObjC/exceptions-personality.m
+5-32 files

LLVM/project 224d3c6clang/lib/StaticAnalyzer/Core HTMLDiagnostics.cpp, clang/test/Analysis/html_diagnostics highlight-range-mapping.cpp

[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]
DeltaFile
+43-0clang/test/Analysis/html_diagnostics/highlight-range-mapping.cpp
+8-27clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
+51-272 files

LLVM/project 257cf94clang/lib/StaticAnalyzer/Core SarifDiagnostics.cpp, clang/test/Analysis/diagnostics sarif-macro-expansion.c

[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]
DeltaFile
+22-21clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
+35-0clang/test/Analysis/diagnostics/sarif-macro-expansion.c
+57-212 files

LLVM/project 20ef11eclang/include/clang/Frontend DiagnosticRenderer.h, clang/lib/Frontend DiagnosticRenderer.cpp

[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
DeltaFile
+89-0clang/unittests/Frontend/TextDiagnosticTest.cpp
+8-1clang/include/clang/Frontend/DiagnosticRenderer.h
+6-0clang/lib/Frontend/DiagnosticRenderer.cpp
+103-13 files

LLVM/project 4aa2d83clang/include/clang/Frontend DiagnosticRenderer.h, clang/lib/Frontend DiagnosticRenderer.cpp TextDiagnostic.cpp

[clang][NFC] Extract getExpansionRangeInFile out of the diagnostic renderers (#214460)

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
DeltaFile
+7-17clang/lib/Frontend/SARIFDiagnostic.cpp
+6-11clang/lib/Frontend/TextDiagnostic.cpp
+15-0clang/lib/Frontend/DiagnosticRenderer.cpp
+9-0clang/include/clang/Frontend/DiagnosticRenderer.h
+37-284 files

LLVM/project 9dfc65dlldb/source/Plugins/ScriptInterpreter/Python PythonDataObjects.cpp

[lldb] Remove Python 2 compatibility in PythonDataObjects.cpp (#215268)

Our minimum Python is 3.8.
DeltaFile
+1-4lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
+1-41 files

LLVM/project 45d4f99llvm/lib/Transforms/InstCombine InstCombineAddSub.cpp, llvm/test/Transforms/InstCombine saturating-add-sub.ll

[InstCombine] Fold uadd.sat(X, C) - C to umin(X, ~C) (#215130)

`uadd.sat(X, C) - C --> umin(X, ~C)` for nonzero `C`.

The saturating add gives `X + C` or `UMAX`, so subtracting `C` leaves
`X` or
`UMAX - C`, which is the unsigned minimum. `UMAX - C == ~C`, so the
constant
is just the inverted `C`.

There was already a test documenting this miss in saturating-add-sub.ll
(`test_scalar_uadd_sub_const`) - it folds now.

https://alive2.llvm.org/ce/z/kLFWy7

Fixes #215103
DeltaFile
+52-2llvm/test/Transforms/InstCombine/saturating-add-sub.ll
+11-1llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp
+63-32 files

LLVM/project 0021505libcxx/utils/libcxx/test/features misc.py

[libc++] Simplify detection of win32-broken-utf8-wchar-ctype (#214797)

Instead of querying `_LIBCPP_HAS_LOCALIZATION` from Python, do it from
the source program. This fixes a bug where if `_LIBCPP_HAS_LOCALIZATION`
was not defined at all (which is the case for older versions of libc++),
the feature would then be defined immediately, regardless of the
platform we're on. That's because `and` has higher precedence than `or`
in Python, so we'd end up skipping the `_WIN32` check entirely.
DeltaFile
+12-6libcxx/utils/libcxx/test/features/misc.py
+12-61 files

LLVM/project 762d376lldb/packages/Python/lldbsuite/test decorators.py lldbtest.py

[lldb][test] Remove Python <= 3.6 workaround (#215262)

re.Pattern was added in 3.7 and our minimum
is now 3.8.

Python 3.6.15:
>>> import re
>>> re.Pattern
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 're' has no attribute 'Pattern'

Python 3.7.17:
>>> import re
>>> re.Pattern
<class 're.Pattern'>

Python 3.8.20:
>>> import re

    [3 lines not shown]
DeltaFile
+2-5lldb/packages/Python/lldbsuite/test/lldbtest.py
+1-3lldb/packages/Python/lldbsuite/test/decorators.py
+3-82 files

LLVM/project 6f65edellvm/lib/Transforms/AggressiveInstCombine AggressiveInstCombine.cpp, llvm/test/Transforms/AggressiveInstCombine/AMDGPU store-merge-addrspace.ll

[AggressiveInstCombine] Don't merge part stores across address spaces (#213677)
DeltaFile
+102-0llvm/test/Transforms/AggressiveInstCombine/AMDGPU/store-merge-addrspace.ll
+5-1llvm/lib/Transforms/AggressiveInstCombine/AggressiveInstCombine.cpp
+107-12 files

LLVM/project 2089961mlir/include/mlir/Interfaces CallInterfaces.td, mlir/lib/Dialect/LLVMIR/IR LLVMDialect.cpp

[mlir][Interfaces] `CallOpInterface`: Model forwarded result + improve verification
DeltaFile
+199-0mlir/test/Interfaces/CallInterfaces/verify-call-op-interface.mlir
+65-37mlir/lib/Dialect/LLVMIR/IR/LLVMDialect.cpp
+68-0mlir/lib/Interfaces/CallInterfaces.cpp
+64-0mlir/test/lib/Dialect/Test/TestOpDefs.cpp
+54-4mlir/include/mlir/Interfaces/CallInterfaces.td
+40-0mlir/test/lib/Dialect/Test/TestOps.td
+490-4115 files not shown
+638-12221 files

LLVM/project 403c96allvm/lib/CodeGen TargetLoweringBase.cpp, llvm/lib/Target/AArch64 AArch64ISelLowering.cpp

Set Expand as default action for ISD::VECTOR_BROADCAST
DeltaFile
+5-3llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
+4-0llvm/lib/CodeGen/TargetLoweringBase.cpp
+9-32 files

LLVM/project 9909d1bllvm/lib/Target/AArch64 AArch64ISelLowering.h AArch64ISelLowering.cpp, llvm/test/CodeGen/AArch64 sve-vector-broadcast.ll

Fix AArch64 ISel for unpacked types

Using DUP instructions only really works for packed types, as it will
not introduce the spacing between elements that is required for unpacked
types like nxv2f16.

For those, we'll first broadcast to their corresponding packed type, and
then extract the lo lanes into an unpacked type, effectively introducing
the required spacing.
DeltaFile
+51-0llvm/test/CodeGen/AArch64/sve-vector-broadcast.ll
+11-31llvm/lib/Target/AArch64/SVEInstrFormats.td
+22-0llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
+1-0llvm/lib/Target/AArch64/AArch64ISelLowering.h
+85-314 files

LLVM/project a325d3dllvm/lib/Target/X86 X86ISelLowering.cpp, llvm/test/CodeGen/X86 vector-shuffle-combining.ll

[X86] combineX86ShuffleChain - bail if source inputs aren't simple vector types (#215249)

Fixes #215111
DeltaFile
+30-0llvm/test/CodeGen/X86/vector-shuffle-combining.ll
+4-0llvm/lib/Target/X86/X86ISelLowering.cpp
+34-02 files

LLVM/project be7be38llvm/lib/CodeGen/SelectionDAG TargetLowering.cpp, llvm/test/CodeGen/RISCV/rvv fixed-vectors-extract.ll

DAG: Use poison instead of undef in SimplifyDemandedVectorElts

I left getKnownUndefForVectorBinop since I'm not sure
if it's correct to just replace with poison.
DeltaFile
+30-38llvm/test/CodeGen/X86/combine-sdiv.ll
+32-18llvm/test/CodeGen/X86/combine-udiv.ll
+11-11llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp
+2-4llvm/test/CodeGen/RISCV/rvv/fixed-vectors-extract.ll
+1-1llvm/test/CodeGen/X86/urem-vector-lkk.ll
+76-725 files

LLVM/project 975b04bllvm/test/CodeGen/AMDGPU amdgcn.bitcast.96bit.ll, llvm/test/CodeGen/X86 build-vector-known-bits-poison.ll kmov.ll

DAG: Skip poison elements in BUILD_VECTOR computeKnownBits (#213326)

This defends against regressions in future patches. Copies the logic
from the IR version of computeKnownBits's handling of ConstantVector.
I'm not sure why the IR version doesn't directly return a value for
poison, but this follows suit.

Co-authored-by: Claude (Claude-Opus-4.8)
DeltaFile
+67-64llvm/test/CodeGen/X86/ifma-combine-vpmadd52.ll
+40-41llvm/test/CodeGen/X86/srem-vector-lkk.ll
+29-21llvm/test/CodeGen/AMDGPU/amdgcn.bitcast.96bit.ll
+8-18llvm/test/CodeGen/X86/pr120906.ll
+9-9llvm/test/CodeGen/X86/kmov.ll
+3-11llvm/test/CodeGen/X86/build-vector-known-bits-poison.ll
+156-1647 files not shown
+183-18613 files

LLVM/project f7e6af8clang/lib/AST/ByteCode Context.cpp Interp.h

[clang][bytecode] Remove the !Caller case in Ret opcodes (#215226)

The bottom frame is always created via an `EvalEmitter`, which has its
own implementation of the `Ret` opcode. The exception is
`Context::Run`/`isPotentialConstantExpr`.
DeltaFile
+18-23clang/lib/AST/ByteCode/Interp.h
+1-1clang/lib/AST/ByteCode/Context.cpp
+19-242 files

LLVM/project 9d3101bllvm/lib/CodeGen/GlobalISel IRTranslator.cpp, llvm/test/CodeGen/AArch64/GlobalISel irtranslator-vector-deinterleave2.ll

[GlobalISel] Fix vector.deinterleave2 with <1 x float> results (#214718)

`translateVectorDeinterleave2Intrinsic` used to try to build
`G_SHUFFLE_VECTOR`
with a scalar result type, which is not valid.
This was the case because the LLT that corresponds to the `<1 x float>`
IR type is a scalar type, not a vector type.

Add a special case for scalar result types to build
`G_EXTRACT_VECTOR_ELT` instead.

Fixes: #214713
DeltaFile
+19-0llvm/test/CodeGen/AArch64/GlobalISel/irtranslator-vector-deinterleave2.ll
+8-0llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
+27-02 files

LLVM/project cc958e4llvm/lib/Target/AArch64 AArch64InstrInfo.td, llvm/lib/Target/AArch64/GISel AArch64InstructionSelector.cpp AArch64RegisterBankInfo.cpp

[AArch64][GlobalISel] Avoid cross bank copies for NEON vcvtfp2fx results (#213277)

Currently, patterns to avoid cross bank copies for the intrinsic
vcvtfp2fx only work with SelectionDAG. This patch allows the DAG
patterns to work with GlobalISel.

 SelectionDAG PR: #210275
DeltaFile
+26-2llvm/lib/Target/AArch64/GISel/AArch64RegisterBankInfo.cpp
+4-6llvm/lib/Target/AArch64/AArch64InstrInfo.td
+9-1llvm/lib/Target/AArch64/GISel/AArch64InstructionSelector.cpp
+5-1llvm/test/CodeGen/AArch64/neon-scalar-vcvtfp2fx.ll
+44-104 files

LLVM/project 2b6174bllvm/test/CodeGen/X86 pext-vector.ll pdep-vector.ll

[X86] Enable pclmul/vpclmulqdq to SSE42+ PDEP/PEXT vector tests (#215244)
DeltaFile
+845-572llvm/test/CodeGen/X86/pdep-vector.ll
+809-551llvm/test/CodeGen/X86/pext-vector.ll
+1,654-1,1232 files

LLVM/project 93edd62lldb/test/API/commands/frame/var TestFrameVar.py, lldb/test/API/lang/cpp/abi_tag_structors TestAbiTagStructors.py

[lldb][test] Mark some tests as requiring Clang (#214197)

As they use clang specific debug information options.
DeltaFile
+4-0lldb/test/API/lang/cpp/template-alias/TestTemplateAlias.py
+4-0lldb/test/API/lang/cpp/abi_tag_structors/TestAbiTagStructors.py
+1-0lldb/test/API/commands/frame/var/TestFrameVar.py
+9-03 files

LLVM/project 878be2fclang/lib/Sema SemaModule.cpp, clang/test/Modules GH204633.cppm

[C++20] [Modules] Don't treat non-named-module as interface unit for implementation unit (#215241)

Close https://github.com/llvm/llvm-project/issues/204633
DeltaFile
+23-0clang/test/Modules/GH204633.cppm
+5-0clang/lib/Sema/SemaModule.cpp
+28-02 files

LLVM/project ce0a0bbclang/lib/StaticAnalyzer/Core HTMLDiagnostics.cpp, clang/test/Analysis/html_diagnostics highlight-range-mapping.cpp

[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]
DeltaFile
+43-0clang/test/Analysis/html_diagnostics/highlight-range-mapping.cpp
+8-27clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
+51-272 files

LLVM/project 15e4cb0clang/lib/StaticAnalyzer/Core SarifDiagnostics.cpp, clang/test/Analysis/diagnostics sarif-macro-expansion.c

[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]
DeltaFile
+22-21clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
+35-0clang/test/Analysis/diagnostics/sarif-macro-expansion.c
+57-212 files