Skip to content

Conversation

@pull
Copy link

@pull pull bot commented Oct 31, 2025

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

@pull pull bot locked and limited conversation to collaborators Oct 31, 2025
@pull pull bot added the ⤵️ pull label Oct 31, 2025
topperc and others added 28 commits November 20, 2025 07:09
…168834)

MachineBasicBlock::liveout_begin() calls this constructor with
MCRegisters so this removes an implicit cast.
The dialect implementation mostly copies the one of `cf.switch`, but
aligns naming to the SPIR-V spec.
This handles the AIX form of the thinLTO cache dir option, which get's
turned on when thinLTO is enabled.
This allows SDNodes to be validated against their expected type profiles
and reduces the number of changes required to add a new node.

I had to split `VSHUF4I` into two variants (`VSHUF4I` and `VSHUF4I_D`)
since `loongarch_vshuf4i` and `loongarch_vshuf4i_d` have different
number of operands, and this prevented the node from being imported.

There is just one node that currently fails validation, see
`LoongArchSelectionDAGInfo::verifyTargetNode()`.

Part of #119709.

Pull Request: #168129
Commit c9f5734 removed the file
TargetLibraryInfo.def but did not remove it from the module map.
LoopPeel sometimes proves that, when reached, the original loop always
executes at least two iterations. LoopPeel then unconditionally executes
both the remaining loop's initial iteration and the peeled final
iteration. But that increases the latter's frequency above its frequency
in the original loop. To maintain the total frequency, this patch
compensates by decreasing the remaininng loop's latch probability.

This is another step in issue #135812 and was discussed at
<#166858 (comment)>.
…68760)

This reverts commit eb20b53.

This relands the compiler-rt internal shell after XRay and Darwin tests
that were failing under the internal shell have been fixed.
#162822 added another
validation step to check if entries in a partial reduction chain have
the same scale factor. But the validation was still dependent on the
order of entries in PartialReductionChains, and would fail to reject
some cases (e.g. if the first first link matched the scale of the second
link, but the second link is invalidated later).

To fix that, group chains by their starting phi nodes, then perform the
validation for each chain, and if it fails, invalidate the whole chain
for the phi.

Fixes #167243.
Fixes #167867.

PR: #168036
Avoids regression which caused the revert 6d5f87f.

This is a hack on a hack. We currently have isUniformMMO,
which improperly treats unknown source value as known uniform.
This is hack from before we had divergence information in the
DAG, and should be removed. This is the minimum change to avoid
the regression; removing the aggressive handling of the unknown
case (or dropping isUniformMMO entirely) are more involved fixes.
Upstream ExtVectorElementExpr with rvalue base
We can't do anything meaningful to such functions: they aren't optimizable, and even if inlined, they would bring no code open to optimization.
To make life easier for future contributors. Note that formatting
changes are due to git clang-format on the touched whitespace-error
lines.
test/Lower/select-case-statement.f90 was still using the old lowering.
Modified the test with FIR generated using the new lowering. Changed the
test to use flang_fc1 instead of bbc and added testing for -O0 and -O1,
since character comparison lowering is done differently at -O0 (uses
runtime function) and -O1 (inlines some cases). Use different FileCheck
prefixes for different optimization levels (CHECK-O0 for -O0, CHECK-O1
for -O1, CHECK for both).
…8292) (#168786)

This reverts commit 6d5f87f.

Previously this failed due to treating the unknown MachineMemOperand
value as known uniform.
…165416)

This PR introduces new debug macros that allow a more fined control of
which debug message to output and introduce C++ stream style for debug
messages.

Changing existing messages (except a few that I changed for testing)
will come in subsequent PRs.

I also think that we should make debug enabling OpenMP agnostic but, for
now, I prioritized maintaing the current libomptarget behavior for now,
and we might need more changes further down the line as we we decouple
libomptarget.
If `HardwareBreakpointTestBase.supports_hw_breakpoints()` returns False,
`SimpleHWBreakpointTest.does_not_support_hw_breakpoints()` returns None,
so the test runs and fails. However, it should be skipped instead.

The test was added in #146602, while `supports_hw_breakpoints()` was
changed in #146609, which was landed earlier despite having a bigger
number.
…econstructing DIE names (#168734)

Depends on: 
* #168725

When compiling with `-glldb`, we repoint the `DW_AT_type` of a DIE to be
a typedef that refers to the `preferred_name`. I.e.,:
```
template <typename T> structure t7;
using t7i = t7<int>;
template <typename T> struct __attribute__((__preferred_name__(t7i))) t7 {};
template <typename... Ts> void f1()

int main() { f1<t7i>(); }
```
would produce following (minified) DWARF:
```
DW_TAG_subprogram
  DW_AT_name      ("_STN|f1|<t7<int> >")
  DW_TAG_template_type_parameter
    DW_AT_type  (0x0000299c "t7i")
...
DW_TAG_typedef
  DW_AT_type      (0x000029a7 "t7<int>")
  DW_AT_name      ("t7i")
```

Note how the `DW_AT_type` of the template parameter is a typedef itself
(instead of the canonical type). The `DWARFTypePrinter` would take the
`DW_AT_name` of this typedef when reconstructing the name of `f1`, so we
would end up with a verifier failure:
```
error: Simplified template DW_AT_name could not be reconstituted:
         original: f1<t7<int> >
    reconstituted: f1<t7i>
```

Fixing this allows us to un-XFAIL the `simplified-template-names.cpp`
test in `cross-project-tests`. Unfortunately this is only tested on
Darwin, where LLDB tuning is the default. AFAIK, there is no other case
where the template parameter type wouldn't be canonical.
Currently the tests for LLVM targets `AArch64` and `ARM` were in the
same directory. But if you only configured LLVM for one target (e.g.,
just `AArch64`, which is how I ran into this), then all tests under the
ARM directory are marked `UNSUPPORTED`.

This patch moves all the tests that are capable of running on
`AArch64`-only targets into a dedicated `AArch64` directory. The tests
that expected a plain `ARM` target were kept in the `ARM` directory.

Drive-by:
* Rename the `dummy-debug-map-amr64.map` to `dummy-debug-map-arm64.map`
(note the typo in `amr64`)
#168619)

I've been working on some scripts that evaluate the parent and child
frame. It's been very annoying that the parent frame has a property but
not the child. So I've added this to the extensions, I would've
preferred to return None, but because the existing impl returns an
invalid SBFrame, so I'm conforming to that API.

```
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> lldb.frame
frame #0: 0x0000555555555200 fib.out`main
>>> lldb.frame.parent
frame #1: 0x00007ffff782a610 libc.so.6`__libc_start_call_main + 128
>>> lldb.frame.parent.child
frame #0: 0x0000555555555200 fib.out`main
```
When downloading bazelisk/buildifier, we use curl, which still returns
exit code zero on HTTP 4xx errors unless we pass --fail. This patch adds
--fail flags so that error messages are more clear.
…168918)

We already know we're looking at BITREVERSE, we can match on the source
operand.
There are several places where we use `llvm::OwningArrayRef`. The
interface to this requires us to first construct temporary storage, then
allocate space and set the allocated memory to 0, then copy the values
we actually want into that memory, then move the array into place.
Instead we can just do it all inline in a single pass by using
`std::vector`. In one case we actually allocate a completely separate
container and then allocate + copy the data over because
`llvm::OwningArrayRef` does not (and can't) support `push_back`.

Note that `llvm::SmallVector` is not a suitable replacement here because
we rely on reference stability on move construction: when the outer
container reallocates, we need the the contents of the inner containers
to be fixed in memory, and `llvm::SmallVector` does not give us that
guarantee.
katzdm and others added 30 commits November 23, 2025 11:11
Fixes #118187
Fixes #156579

An instantiated `LambdaExpr` can currently be marked as
`LDK_NeverDependent` if it's nested within a generic lambda. If that
`LambdaExpr` in fact depends on template parameters introduced by the
enclosing generic lambda, then its dependence will be misreported as
"never dependent" and spurious diagnostics can result.

The fix here proposed is a bit ugly, but the condition that it's being
bolted onto already seems like a bit of a hack, so this seems no worse
for wear.

Note that #89702 surfaced this change because it caused the inner lambda
expression to (correctly) be considered in a constant-evaluated context.
The affected check for whether to mark the inner lambda as
`LDK_NeverDependent` therefore started to apply, whereas it didn't
before.

**Tested**: `check-clang` and `check-cxx`.
…Reg (#168661)"

This reverts commit 0859ac5.

This caused a couple test failures, likely due to a mid-air collision.
Reverting for now to get the tree back to green and allow the original
author to run UTC/friends and verify the output.
…#169182)

I think we need to keep the SelectionDAG code for volatile load/store so
we should support 4 byte alignment when possible.
BugSuppression works by traversing the lexical decl context of the
decl-with-issue to record what source ranges should be suppressed by
some attribute.
Note that the decl-with-issue will be changed to the lexical decl
context of the original decl-with-issue, to make suppression attributes
work that were attached to the CXXRecordDecl containing the
CXXMethodDecl (bug report's DeclWithIssue).

It happens so that it uses a DynamicRecursiveASTVisitor, which has a
couple of traversal options. Namely:

 - ShouldVisitTemplateInstantiations
 - ShouldWalkTypesOfTypeLocs
 - ShouldVisitImplicitCode
 - ShouldVisitLambdaBody

By default, these have the correct values, except for
ShouldVisitTemplateInstantiations. We should traverse template
instantiations because that might be where the bug is reported - thus,
where we might have a [[clang::suppress]] that we should honor.

In this patch I'll explicitly set these traversal options to avoid
further confusion.

rdar://164646398
#168885)

Add two more AST nodes, one for a misplaced end-directive, and one for
an invalid string following the OpenMP sentinel (e.g. "!$OMP XYZ").

Emit error messages when either node is encountered in semantic
analysis.
…ant fold (#169217)

Extension to #168726 - ensure we peek through bitcasts to look for
constants (as constant folding will)

DAG should have constant folded this, but we're still fighting the lack
of proper topological sorting.

Fixes #169205
Fold
  any-of (fcmp uno %A, %A), (fcmp uno %B, %B), ... ->
  any-of (fcmp uno %A, %B), ...

This pattern is generated to check if any vector lane is NaN, and
combining multiple compares is beneficial on architectures that have
dedicated instructions.

Alive2 Proof: https://alive2.llvm.org/ce/z/vA_aoM

Combine suggested as part of
#161735

PR: #166823
Make it easier to use these containers as drop-in replacements for
std::map.
… and flangFrontend (#165277)

This removes the dependency on clangDriver from clangFrontend and
flangFrontend.

This refactoring is part of a broader effort to support driver-managed
builds for compilations using C++ named modules and/or Clang modules.
It is required for linking the dependency scanning tooling against the
driver without introducing cyclic dependencies, which would otherwise
cause build failures when dynamic linking is enabled.
In particular, clangFrontend must no longer depend on clangDriver
for this to be possible.

This change was discussed in the following RFC:
https://discourse.llvm.org/t/rfc-new-clangoptions-library-remove-dependency-on-clangdriver-from-clangfrontend-and-flangfrontend/88773
This PR adds `__builtin_operator_new` and `__builtin_operator_delete`.

The implementation is taken from clang code gen.
The CMake
[`set()`](https://cmake.org/cmake/help/latest/command/set.html) command
does not accept a conditional expression as a value. As a result,
AFFECTED_BY_SWIG_BUG was being set to a string representation of the
condition rather than a boolean value, causing it to always evaluate as
truthy in subsequent if-checks.
This test does not actually need to use the clang driver. Using the
driver means that the environment plays much more into the tests
results. We ran into a situation where the driver decided not to pass
-fopenmp to the cc1 invocation, causing the test to fail.

This also makes the test more consistent with the other OpenMP tests and
should make it slightly faster (no subprocess invocation).
I was the SelectionDAG maintainer (then called code owner) from
aebfacb (requested to take it up by
Evan Cheng) and yielded the role to Justin Bogner as of
d8ed65d.
Co-authored-by: Aiden Grossman <[email protected]>
Fix VPlan SLP check incorrectly bailing out for non-VPInstructions.
Starting from the beginning of the block will include canonical IVs,
which in turn are not VPInstructions. If we hit a non-VPInstruction, we
should conservatively treat is as potentially unvectorizable.

To keep the tests working as expected, refine mayRead/WriteFromMemory
for Load and GEP VPInstructions.
e5edb51 attempted to port this, but
seemed to miss a couple things that still showed up on CI. This patch
fixes up the missing pieces.
#167060)" (#169238)

This reverts commit a52e1af.

That commit reverted a change (making isExpandedFromMacro take a
std::string) that was explicitly added to avoid lifetime issues. We ran
into issues with some internal matchers due to this, and it probably is
not an uncommon downstream use case. This patch restroes the original
functionality and adds a test to ensure that the functionality is
preserved.

https://reviews.llvm.org/D90303 contains more discussion.
…64768)

Background: X86 APX feature adds 16 registers within the same 64-bit
mode. PR #164638 is trying to extend such registers for FASTCC. However,
a blocker issue is calling convention cannot be changeable with or
without a feature.

The solution is to disable FASTCC if APX is not ready. This is an NFC
change to the final code generation, becasue X86 doesn't define an
alternative ABI for FASTCC in 64-bit mode. We can solve the potential
compatibility issue of #164638 with this patch.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.