[Coroutines] Use destroy slot for CoroElide resume fallthrough
Fixes https://github.com/llvm/llvm-project/issues/188230
A switch coroutine with a CoroElide noalloc variant uses the frame destroy slot as a runtime discriminator: heap-allocated frames store the destroy clone, while allocation-elided frames store the cleanup clone. Its resume clone can reach a fallthrough coro.end after the final suspend.
The coroutine body can invoke a continuation before reaching that coro.end. A suspend_never continuation can complete and free its frame before control returns. When the callee frame was elided into that caller allocation, loading the destroy slot at coro.end reads freed storage, which AddressSanitizer reports as a use-after-free.
Load and cache the destroy function in the switch-resume entry block before executing the resume body, then tail-call the cached value at fallthrough coro.end. The cache retains the frame slot as the allocation discriminator without dereferencing an elided frame after the continuation returns.
Add a C++ CodeGen regression for the original suspend_never final-suspend shape and update CoroSplit tests to require the entry load.
Assisted-By: Codex GPT 5.5
[AMDGPU] Run early-cse<memssa> at the end of the full-LTO pipeline (#208461)
The regular (non-LTO) and ThinLTO function simplification pipelines run
an
EarlyCSE-with-MemorySSA pass near the start of the function pass
sequence, but
the full-LTO postlink pipeline does not. Without it, a redundant
load/store
round-trip can survive all the way to codegen; the later GVN/DSE in the
LTO
pipeline do not catch this particular pattern.
Rather than touch the target-independent LTO pipeline, register
early-cse<memssa> through the AMDGPU FullLinkTimeOptimizationLast
extension
point, so it runs at the end of the full-LTO middle-end (before codegen)
only
for AMDGPU.
Assisted-by: Claude Opus
[libc] Omit -fpie from the full build (#208343)
We shouldn't unconditionally set -fpie, users should be able to control
this with CMAKE_POSITION_INDEPENDENT_CODE.
[libc][math] Implement half precision lgamma function (#192834)
The implementation uses three distinct paths based on $|x|$:
- Small ($|x| < 0.66$): Fits a degree-12 Chebyshev for $h(t) =
\frac{\text{lgamma}(t) + \log(t)}{t}$, recovering $\text{lgamma}(t) = t
\cdot h - \log(t)$.
- Medium ($|x| \in [0.66, 3.37]$): Fits a degree-20 Chebyshev for $g(t)
= \frac{\text{lgamma}(t)}{(t-1)(t-2)}$
- Stirling ($|x| > 3.37$): Uses $(x-0.5) \cdot \log(x) - x +
\frac{\log(2\pi)}{2}$ plus 1/2/4/8-term Bernoulli corrections by
sub-range.
Special cases: NaN, +/-Inf -> +Inf, +/-0 pole, negative integer pole,
lgamma(1) = lgamma(2) = 0 exactly, overflow for large positive x.
Exhaustive tests pass in all 4 rounding modes.
[6 lines not shown]
[Github] Install `llvm-tools` in libc container (#210414)
Currently, the libc container doesn't contain `llvm-tools`. we need to
use them in #200196 because we are not able to use `llvm-lit` without
building clang from source
[InstCombine] Fix 0.0 / x -> 0 folds when the divisor may be zero (#202482)
SimplifyDemandedUseFPClass folded 0/x to a signed zero, guarded only on
the divisor being non-NaN. But when x==0, the result is is NaN, not 0!
Require the divisor to be never (logical) zero, unless a NaN result
isn't demanded.
[IR][NFC] Avoid unneccessary move of analysis results (#210540)
While benchmarking CycleAnalysis, I noticed that each analysis result is
constructed on the stack first and then moved to its final place on the
heap. This is unnecessary -- directly construct the analysis result in
its final place. Consequently, analysis results can be immovable.
[DirectX] Fix `--dx-embed-debug` flag dependency (#210513)
This patch moves the definition of `cl::opt<std::string> PdbDebugPath`
from `DXContainerGlobals.cpp` to `DXILWriter/DXILWriterPass.cpp`,
reversing the dependency.
Fixes the layering violation in #204166.
[mlir-c] Expose hard-failure state in 1:N type conversion callback
The 1:N conversion callback returned MlirLogicalResult, which the binding
could only map to success or nullopt (try-another), leaving the C++
failure() state (fail without trying another conversion) unreachable.
Return a MlirTypeConverterConversionStatus enum instead, with Success,
Failure, and Declined states mapped to success(), failure(), and
std::nullopt respectively. Add a test covering the hard-failure path.
[mlir-c] Expose hard-failure state in 1:N type conversion callback
The 1:N conversion callback returned MlirLogicalResult, which the binding
could only map to success or nullopt (try-another), leaving the C++
failure() state (fail without trying another conversion) unreachable.
Return a MlirTypeConverterConversionStatus enum instead, with Success,
Failure, and Declined states mapped to success(), failure(), and
std::nullopt respectively. Add a test covering the hard-failure path.
[mlir-c] Value-initialize MlirConversionPatternCallbacks in Python bindings
The Python conversion-pattern binding left the struct default-initialized,
so the newly-added optional matchAndRewrite1ToN field held an indeterminate
pointer. The driver's null check then read garbage and jumped into it,
segfaulting mlir/test/python/rewrite.py. Value-initialize the struct so
optional callbacks default to null.
[mlir-c] Add 1:N TypeConverter conversion and materialization bindings
Builds on the source/target materialization C bindings:
- Target materialization callbacks now receive `originalType` (split from the
previously-shared source/target callback typedef), exposing a documented C++
capability that was otherwise unreachable from C.
- 1:N type conversion: `mlirTypeConverterAdd1ToNConversion` plus an opaque
results accumulator (`MlirTypeConverterConversionResults` /
`mlirTypeConverterConversionResultsAppend`). A declining callback's appended
types are rolled back so the driver's "try the next conversion" invariant
holds.
- 1:N target materialization: `mlirTypeConverterAdd1ToNTargetMaterialization`,
whose callback fills a caller-allocated `outputs` buffer. A success that
leaves any output null is treated as a decline rather than handing the driver
a null-containing result.
- `mlirConversionPatternRewriterReplaceOpWithMultiple` for 1:N value
replacement, which can drive a source materialization with nInputs > 1.
- An optional `matchAndRewrite1ToN` callback on `MlirConversionPatternCallbacks`
[9 lines not shown]
[mlir-c] Fix -Wmissing-field-initializers in rewrite.c test
The new matchAndRewrite1ToN field left three existing
MlirConversionPatternCallbacks initializers under-initialized, which
fails the CI build under -Werror=-Wmissing-field-initializers.
