[MLIR][ODS] Add strict property assembly format mode
Introduce a dialect-level ODS flag for strict property handling in declarative
assembly formats. It is disabled by default for now, preserving existing parser
behavior unless a dialect opts in.
Enable the mode immediately for dialects whose declarative assembly formats
already satisfy these binding rules.
When enabled, a property-backed op format must bind every inherent attribute
and property directly or include prop-dict.
Generated parsers for opted-in dialects also reject inherent attributes that
arrive through attr-dict, preventing Operation::setAttrs from populating
properties through that path.
Add mlir-tblgen coverage and document default and strict dialect behavior.
Assisted-by: Codex
[SelectionDAG] Support vector types in llvm.convert.from.arbitrary.fp expansion (#196185)
Move the bit-twiddling expansion of ISD::CONVERT_FROM_ARBITRARY_FP from
LegalizeDAG to TargetLowering and make it working on vector destination
types.
[TableGen][GlobalISel] Skip REG_SEQUENCE with incompatible subreg index (#196184)
The REG_SEQUENCE branch of GlobalISelEmitter::constrainOperands called
SuperClass->getMatchingSubClassWithSubRegs(...) and dereferenced the
returned SrcRCDstRCPair unconditionally, aborting on a libstdc++
optional assertion when incorrect subreg index was passed.
Add the missing guard so the malformed pattern is reported via
failedImport (a skipped pattern) instead of crashing tblgen.
Assisted by Claude.
Fixes https://github.com/llvm/llvm-project/issues/172690
[mlir][SPIR-V] Add support for SPV_INTEL_long_composites extension (#195685)
Add serialization and deserialization support for the
SPV_INTEL_long_composites extension, which allows splitting
composite/struct instructions that exceed the SPIR-V 16-bit word count
limit (65535 words) into a head instruction followed by one or more
continuation instructions
[LV][NFC] Remove simplifycfg pass from RUN lines (#195817)
All the simplifycfg pass really did was remove empty blocks. I don't
believe it added any real value, but it does make the tests run slower.
[clang-tidy] Reject malformed -std spellings in `check_clang_tidy.py`. NFC. (#195609)
`check_clang_tidy.py` expanded any `-std` value containing `-or-later`,
even when extra text followed the suffix. e.g. `c++20-or-latermisc` was
treated like `c++20-or-later`.
This commit requires `-or-later` to be the actual end of the spelling
before expanding it, so malformed values are passed through and
diagnosed by clang.
[AArch64][GlobalISel] Clean up and extend BF16 tests. NFC (#196175) (#196255)
This attempts to fill in the gap between the different bf16 test files,
making sure they all contain the same tests.
[Docs] Warn against extremely wide integer types in PerformanceTips (#192275)
Following the discussion, this patch adds a warning to the
PerformanceTips documentation regarding the use of extremely wide
integer types.
The LLVM optimizer and certain analysis passes (like ConstantRange) are
not designed to handle integer types exceeding a few thousand bits,
which can lead to super-linear complexity and significant compile-time
hangs. Frontend authors are advised to decompose such large integers
into machine-word-sized pieces instead.
Fixes #192277
Co-authored-by: Claude Opus 4.7 (1M context) <noreply at anthropic.com>
[LangRef] Adjust reduce.fmin/reduce.fmax behavior for sNaN (#196053)
The reduce.fmin/reduce.fmax intrinsics are designed as unordered
reductions, just like all reductions that do not take a start value.
However, if one of the elements is sNaN, then the reduction order
matters.
I *tried* to account for this when implementing the sNaN changes for
minnum/maxnum in LangRef, but didn't correctly consider the
consequences: It's not sufficient to just say that if one value is sNaN,
either the result is NaN or its treated as qNaN.
For example, if we reduce over `<sNaN, 0.0, 1.1>` then (picking the IEEE
behavior for each maxnum):
* maxnum(maxnum(sNaN, 0.0), 1.0) = maxnum(qNaN, 1.0) = 1.0
* maxnum(maxnum(sNaN, 1.0), 0.0) = maxnum(qNaN, 0.0) = 0.0
* maxnum(maxnum(0.0, 1.0), sNaN) = maxnum(1.0, sNaN) = qNaN
[5 lines not shown]
[SCEV] Merge udiv exact logic into general udiv logic (#195840)
The udiv exact handling for constant RHS is already partially handling
in the generic udiv code:
https://github.com/llvm/llvm-project/blob/8a0c5d3f43b27c8e2895c6106d6b551d626979fd/llvm/lib/Analysis/ScalarEvolution.cpp#L3641-L3657
Move two remaining folds there as well:
* `(%a * %b)<nuw> / %b` to `%a`
* `(A*GCD * %b)<nuw> / (C*GCD)` to `(A * %b)<nuw> / C`
Removing common factors from a multiply does not require exact if the
multiply is nuw (and conversely, being exact is not sufficient without
nuw).
This makes getUDivExactExpr() equivalent to getUDivExpr(). I've retained
the method for now in case we want to add exact specific logic in the
future.
Proof: https://alive2.llvm.org/ce/z/iQeb6v
[mlir][Interfaces] Allow integer types for `ValueBoundsOpInterface` (#196082)
Allow integer-typed SSA values in the `ValueBoundsConstraintSet`
infrastructure. Only index types were allowed until now. This new
feature is opt-in only. The implementation assumes that integer
computation will not overflow.
A new `ValueBoundsOptions` struct is added. Public entry points now take
this struct instead of the `closedUB` flag. The flag was moved to the
options struct, along with the `allowIntegerType` flag.
Note for LLVM integration: Pass `ValueBoundsOptions` instead of `bool
closedUB`.
Assisted-by: gpt-5.5-extra-high
[RISCV][MC][NFC] Update IME vtype layout to match latest spec `riscv-isa-release-fa55752-2026-05-04` (#195998)
This updates the IME-specific vtype field layout to match the [latest
IME spec, version
riscv-isa-release-fa55752-2026-05-04](https://github.com/riscv/integrated-matrix-extension/blob/main/src/integrated-matrix.adoc#new-fields-in-the-vector-type-vtype-register).
The latest spec places the IME fields as:
| Field | New Position | Change Description |
|---------------|---------------------------|---------------------------------|
| `lambda[2:0]` | `vtype[XLEN-2:XLEN-4]` | Unchanged |
| `bs` | `vtype[XLEN-5]` | Moved from `vtype[XLEN-7]` |
| `altfmt_A` | `vtype[XLEN-6]` | Moved from `vtype[XLEN-5]` |
| `altfmt_B` | `vtype[XLEN-7]` | Moved from `vtype[XLEN-6]` |
Previously `bs`, `altfmt_A`, and `altfmt_B` followed the older ordering,
which was first introduced in #193956. The new position of altfmt
supports growing in the future for more datatypes.
This patch also updates tests to reflect field changes.
Currently this should be NFC since we didn't have any CodeGen
implementation that involves vtype in IME.
[libc][docs] Minor typos in Documentation (#196066)
- removed a duplicate "to" in dev/undefinde_behaviour.rst
- corrected "in order or link" to "inorder to link" in gpu/using.rst
Signed-off-by: udaykiriti <udaykiriti624 at gmail.com>
[InstCombine] Drop alignment assumptions more aggressively (#196060)
`computeKnownBits` gets a context instruction now, which allows dropping
assumes based on previous assumes.
