llvm: Remove phantom fp-contract-model attributes from tests
This attribute has never been consumed by upstream llvm,
or emitted by upstream clang. I can only guess this existed in
at least one downstream fork.
[VPlan] Append recipes created via builder to worklist
The previous PR appended the top most created recipe to the worklist, and this PR extends it to any other nested recipes that were created, similar to InstCombine.
This removes the header mask in a good few more places on RISC-V as measured on SPEC CPU 2017, e.g. for the following loop:
```c
long f(const int *p, const int *q, long n) {
long a = 0, b = 0;
for (long i = 0;; i++) {
if (p[i] && q[i]) { a += i; b += i; }
if (i + 1 == n) break;
}
return a + b;
}
```
Before:
[49 lines not shown]
[SelectionDAG] Widen vector math libcalls when no routine is available (#218948)
`tryExpandVecMathCall` currently only checks for a vector math routine
matching the node's exact vector type, unrolling when none is found.
This is suboptimal, and can lead to crashes for scalable types (which
cannot be unrolled).
This PR implements widening to first check if a routine with a wider vec
type exists before falling back to unrolling.
Example:
```
; llc -mtriple=aarch64 -mattr=+sve -vector-library=sleefgnuabi crash.ll
define <vscale x 2 x float> @frem_nxv2f32(<vscale x 2 x float> %a, <vscale x 2 x float> %b) {
%res = frem <vscale x 2 x float> %a, %b
ret <vscale x 2 x float> %res
}
```
[2 lines not shown]
Switch to SmallVector with space on stack
SmallVector allows for much larger small sizes than SetVector, so use 256 to match InstructionWorklist.
We don't need to worry about duplicate worklist entries until we add users to the worklist.
[VPlan] Process simplifyRecipes in a worklist
This brings simplifyRecipes further in line with InstCombine, and asides from unlocking more simplifications it also helps avoid spurious test churn whenever passes are moved around simplifyRecipes.
For now just push the new recipe onto the worklist, not its users.
This uses a post order traversal so we maintain the same simplification order as before.
I've gone through and checked every simplification we do is a canonicalisation that converges, and I checked on llvm-test-suite + SPEC CPU 2017 in various configurations that we don't hit any cycles.
[SPIRV] Preserve DebugGlobalVariable emission order. (#221759)
Iterate GlobalVariableDebugInfoMap with MapVector so OpString and
DebugGlobalVariable follow insertion order.
The following tests had non-deterministic output, although didn't fail
due to the use of CHECK-DAG:
- llvm/test/CodeGen/SPIRV/debug-info/debug-global-variable-multi-gve.ll
- llvm/test/CodeGen/SPIRV/debug-info/debug-lexical-block-namespace.ll
- llvm/test/CodeGen/SPIRV/debug-info/debug-type-pointer.ll
[VPlan] Split simplifyRecipes into simplifyRecipes and combineRecipes
Bringing it in line with InstSimplify and InstCombine, split up simplifyRecipe into a function that modifies and creates recipes (combineRecipe), and one that is analysis-only (simplifyRecipe).
This allows us to avoid adding simplficiation only folds to the worklist in #213899.
The funclet.ll test no longer erases the constant-folded intrinsic call because vputils::isDeadRecipe returns false.
[clang] Unique more ASTContext type pools in a UniquingSet. NFC (#221898)
Similar to #221850.
Eight pools key on a small tuple of types, integers and pointers, yet
each get*Type() serializes that into a FoldingSetNodeID and hashes it
out of line before probing. Switch to UniquingSet.
These getters re-probe after building the canonical type. A token is a
hash (#218190), not a bucket, so nothing invalidates it. Drop unneeded
assertions.
GlobalISel: Drop AllowFPOpFusion from CombinerHelper FMA formation
Only rely on the contract flags.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
py-eth-hash: updated to 0.8.0
0.8.0
No significant changes.
0.8.0-beta.1
Breaking Changes
Drop support for Python 3.8 and 3.9
Features
Add support for Python 3.14
[CIR][CMake] Configure MLIR as a dependency-only project
ClangIR requires MLIR, but enabling CIR currently requires users to list MLIR
explicitly in LLVM_ENABLE_PROJECTS. That also attaches all MLIR build, install,
unit-test, and lit targets to the corresponding LLVM aggregates.
When Clang is selected and CLANG_ENABLE_CIR is enabled, append MLIR to the
effective LLVM_ENABLE_PROJECTS list. The common project setup compares that
list with the cached user selection, so an explicit MLIR selection retains its
normal behavior while an implicit selection is configured with EXCLUDE_FROM_ALL.
This makes MLIR targets available for CIR dependency resolution without adding
MLIR's aggregate targets. Keep the existing standalone ClangIR restriction and
do not configure MLIR when CIR is disabled.
Validation:
- Configured Clang with CIR and implicit MLIR test support.
- Configured Clang and MLIR explicitly with CIR and tests enabled.
- Configured Clang without CIR and verified that MLIR remains disabled.
[4 lines not shown]
