[mlir][IR] Require token producer and consumer traits
Add marker traits for operations that intentionally produce or consume the
builtin token type. The verifier now rejects token results without
TokenProducerTrait, token operands without TokenConsumerTrait, token entry
block arguments whose parent op does not produce tokens, and token block
arguments outside entry blocks.
Extend the Test dialect token ops to cover valid opt-in cases and each
verifier rejection path.
Assisted-by: Codex
[mlir][async] Lazily create the coroutine destroy-cleanup block
`setupCoroMachinery` previously emitted a `cleanupForDestroy` block
unconditionally, alongside the normal `cleanup` block. That block is
only ever used as the "destroy" successor of an `async.coro.suspend`,
so for coroutines that never suspend (e.g. an `async.func` whose body
contains no `async.await`) it ended up unreachable in the lowered CFG.
Make `cleanupForDestroy` mirror the existing `setError` pattern and
materialize it lazily via a new `setupCleanupForDestroyBlock` helper,
called only from the two places (`outlineExecuteOp` and the
`async.await` lowering) that actually wire it up. Store the coroutine
id on `CoroMachinery` so the helper can rebuild the block contents
without keeping the original `async.coro.id` op around.
Assisted-by: Opus 4.7
[InstrProf] Do not emit metadata for zero values with zero counts (#199380)
If we have a indirect call site with a profile that has VP information
for said callsite that only contains zero values with zero counts, we
would start to emit invalid profile information after
1d146967d51ba76b8379d9e12961aa23e5745701. VP metadata in this case is at
best redundant with BFI. So we restrict metadata emission to only if we
have a sufficient number of values for the VP metadata to be valid.
[mlir][async] Lazily create the coroutine destroy-cleanup block
`setupCoroMachinery` previously emitted a `cleanupForDestroy` block
unconditionally, alongside the normal `cleanup` block. That block is
only ever used as the "destroy" successor of an `async.coro.suspend`,
so for coroutines that never suspend (e.g. an `async.func` whose body
contains no `async.await`) it ended up unreachable in the lowered CFG.
Make `cleanupForDestroy` mirror the existing `setError` pattern and
materialize it lazily via a new `setupCleanupForDestroyBlock` helper,
called only from the two places (`outlineExecuteOp` and the
`async.await` lowering) that actually wire it up. Store the coroutine
id on `CoroMachinery` so the helper can rebuild the block contents
without keeping the original `async.coro.id` op around.
Assisted-by: Opus 4.7
[mlir][async] Lazily create the coroutine destroy-cleanup block
`setupCoroMachinery` previously emitted a `cleanupForDestroy` block
unconditionally, alongside the normal `cleanup` block. That block is
only ever used as the "destroy" successor of an `async.coro.suspend`,
so for coroutines that never suspend (e.g. an `async.func` whose body
contains no `async.await`) it ended up unreachable in the lowered CFG.
Make `cleanupForDestroy` mirror the existing `setError` pattern and
materialize it lazily via a new `setupCleanupForDestroyBlock` helper,
called only from the two places (`outlineExecuteOp` and the
`async.await` lowering) that actually wire it up. Store the coroutine
id on `CoroMachinery` so the helper can rebuild the block contents
without keeping the original `async.coro.id` op around.
Assisted-by: Opus 4.7
Revert "[compiler-rt][ASan] Add function copying annotations (#91702)" (#194204)
This reverts commit c76045d9bf3bd1c7a381dc85d1db63a38fd69aa4.
It does not look like this has been used anywhere since it was
implemented. I see no uses of it in LLVM, anywhere in our internal
monorepo, or across the entirety of Github outside of other copies of
LLVM tests. Given that, remove it. The intended use case around SSO ASan
string annotations is also likely to be significantly reworked soon.
[lit] Normalize RLIM_INFINITY to "infinity" in print_limits.py for Python 3.15+ (#190953)
Python 3.15 changed resource.getrlimit() to return the platform's
maximum value (e.g., 18446744073709551615 on 64-bit systems) instead of
-1 for RLIM_INFINITY. This breaks lit tests that expect -1 for unlimited
resource limits.
This patch normalizes the return value to "infinity" when it equals
RLIM_INFINITY to maintain compatibility with existing tests across all
Python versions.
Fixes test failure: shtest-ulimit-nondarwin.py
Expected: RLIMIT_FSIZE=-1
Got: RLIMIT_FSIZE=18446744073709551615
Reference:
https://github.com/python/cpython/commit/0324c726dea702282a0300225e989b19ae23b759
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=2448969
[7 lines not shown]
[ProfData] Remove HWAsan exclusion (#199582)
This passes locally for me with HWAsan enabled on a AArch64 machine, so
it seems like this might have been fixed since adding the opt-out.
[AMDGPU] Don't assume non-erased DenseMap entries remain valid after erase. NFC (#199578)
In preparation for DenseMap change that relocates surviving entries on
erase, replace erase-while-iterating with remove_if.
[NVPTX] Don't assume non-erased DenseMap entries remain valid after erase. NFC (#199575)
GenericToNVVM erases entries from GVMap while iterating it. In
preparation for DenseMap change that relocates surviving entries on
erase, snapshot the map and erase by key.
