Skip to content

[pull] main from llvm:main - #1709

Merged
pull[bot] merged 10 commits into
MPACT-ORG:mainfrom
llvm:main
Aug 3, 2026
Merged

[pull] main from llvm:main#1709
pull[bot] merged 10 commits into
MPACT-ORG:mainfrom
llvm:main

Conversation

@pull

@pull pull Bot commented Aug 3, 2026

Copy link
Copy Markdown

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 : )

trg-rgb and others added 10 commits August 3, 2026 00:01
…smatch (#202201)

combineBinOpOfExtractToReduceTree asserts that the extract source
vector's element type equals the binop's value type
(SrcVecVT.getVectorElementType() == VT). This invariant does not hold
for all valid inputs.

A <1 x i1> binary operation under -mattr=+zve32x reaches this point with
the source vector element type differing from VT, which trips the
assertion in an assertions-enabled build and silently proceeds on a
false assumption otherwise.

Convert the assertion into an early return, so the combine declines when
its precondition is not met. This matches the existing bail-out style in
the same function (the isScalableVector and getScalarSizeInBits() >
getELen() checks immediately following). The change only ever skips the
fold; it never alters correct output.

Generative AI was used for the test case. The fix
is mine. Bug found by fuzzing with llvm-stress (seed 96) and reduced
with llvm-reduce.

Signed-off-by: Tanmay Gulhane <tanmaygulhane12@gmail.com>
)

`llvm-mc` asserts on a VCMP predicate given as a symbol:

```asm
vcmpps $f0, %xmm0, %xmm1, %xmm2
```

```
Assertion failed: isImm() && "This is not an immediate", MCInst.h:85
```

`optimizeInstFromVEX3ToVEX2` reads the predicate with `getImm()` to
decide whether the operands commute. A symbolic predicate is not known
until link time, so that decision cannot be made here. Decline the
shrink instead.

Unlike the sibling FPCLASS issues (#185364, #185365) this one is on the
encoding path and asserts under `--filetype=obj` too, so a release build
would be making the commutation decision on whatever `getImm()` returns
for a non-immediate.

Literal predicates are unaffected and still commute to reach the
two-byte VEX prefix. The test covers both.

Fixes #185355
The PR updated: riscv/riscv-isa-manual#1564

---------

Co-authored-by: Craig Topper <craig.topper@sifive.com>
…FC) (#213408)

This patch implements contains(StringRef) and contains(uint64_t) in
SampleProfileNameTable and SampleProfileReader to serve symbol
membership queries directly from the reader -- "is this symbol in the
name table?".

Without this patch, users of the sample profile reader, namely
SampleProfileLoader::doInitialization and SampleProfileNameSet, each
construct their own StringSet<> containing all name table entries.
That is, we end up with two instances of StringSet<> with identical
contents.  Since these instances hold their own copies of symbol
strings on the heap, both the constructor and destructor take up a
large portion of compilation time.

This patch teaches SampleProfileReader::contains to directly serve
symbol membership queries.

- For EytzingerSampleProfileNameTable, contains performs binary search
  directly across the three concatenated Eytzinger table spans
  (CSKeys, FlatKeys, and Inlinees) in a cache-friendly manner.

- Other representations of the name table lazily construct an internal
  DenseSet on demand.

This patch updates existing customers to call Reader->contains.

This patch fixes a build issue on 32-bit ARM.

RFC:
https://discourse.llvm.org/t/rfc-faster-sample-profile-loading/90957/8

Assisted-by: Antigravity
These tests appear to have been copy paste from other image error
tests, which were checking for invalid argument validation. The point
of these tests were to reject image builtins on unsupported targets,
and not just gfx942. Rename the tests, and fix the invalid argument
usage. Each builtin should be used in a valid way.

Co-authored-by: Claude (Claude-Opus-4.8)
…object dummy names (#210876)

Fixes #206913

Issue:
Flang wrongly accepts a type-bound procedure override when the
implementing procedure uses a different dummy name than the parent
deferred interface.

Root cause:
The PASS override check uses CanOverride, which compares dummy types but
not dummy names for the passed-object argument.

Fix:
Check that dummy names match before CanOverride and report a clear error
Dropping a channel from a sparse DMask removes that write entirely

It does not zero-fill like a contiguous trim does

Only simplify stores when DMask is a contiguous prefix
@pull pull Bot locked and limited conversation to collaborators Aug 3, 2026
@pull pull Bot added the ⤵️ pull label Aug 3, 2026
@pull
pull Bot merged commit 4f607e3 into MPACT-ORG:main Aug 3, 2026
3 of 5 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants